intentional time step of one second to adjust UTC to ensure appropriate agreement with UT1, a time scale based on the rotation of the Earth Rec. ITU-R TF.460-5

トレンドマイクロでは、以下のリストにある製品で影響を受ける可能性がある事を確認しております。詳細については以下の表から回避方法をご確認ください。

NTPを有効なまま、うるう秒を迎えると、CPUの負荷が高騰する可能性があります。

A positive leap second will be introduced at the end of December 2016.

The sequence of dates of the UTC second markers will be:

2016 December 31, 23h 59m 59s

2016 December 31, 23h 59m 60s

2017 January 1, 0h 0m 0s

8.7 うるう秒における字幕表示

字幕表示のタイミングは、放送局から放送波により伝送される NTP と同期する受信機内時計に

より処理される。しかし、NTP は UTC を利用しているため、「うるう秒」という事象が発生する。

この「うるう秒」が発生した場合であっても、放送局が想定する正確なタイミングで字幕表示を補

正処理する必要がある。

8.7.1 うるう秒発生時のMH-データ符号化方式記述子の付加識別情報の運用

reference_start_time がうるう秒発生時刻の 24 時間より前の場合には、

reference_start_time_leap_indicator の値は”0”となる。

時刻追加の場合は、付加識別情報に記述される reference_start_time の値が、うるう秒発生前日

の 9:00:00 からうるう秒当日の 8:59:59 の場合には、reference_start_time_leap_indicator は値と

して”1”となり、それ以外の場合は”0”となる。

時刻削除の場合は、付加識別情報に記述される reference_start_time の値が、うるう秒発生前日

の 9:00:00 からうるう秒当日の 1 回目の 8:59:58 の場合には、reference_start_time_leap_indicator

は値として”2”となり、それ以外の場合は”0”となる。

なお、放送事業者によっては、うるう秒における時刻補正処理をサービス休止期間に実施する運

用も想定されている、その場合は付加識別情報の reference_start_time_leap_indicator は”0”のみ

が運用される。

8.7.2 うるう秒発生時の字幕表示タイミングの補正

MH-データ符号化方式記述子の付加識別情報を利用した、字幕表示タイミングの補正処理のガイ

ドラインを付録 2 に示す。

The range [0,60] seconds allows for positive or negative leap seconds. The formal definition of UTC does not permit double leap seconds, so all mention of double leap seconds has been removed, and the range shortened from the former [0,61] seconds seen in previous versions of POSIX.

うるう秒は、一度に 2 秒入ることはないのだが、C89(の脚注、および K&R2e)で秒のレンジが 0〜61 とされて以来、標準規格などでもそれを踏襲して「double leap seconds」に「対応」していた。POSIX 2004(Rational によれば UTC の定義によって double leap seconds は無い、ということを理由に)など、近年修正されつつある → http://www.opengroup.org/onlinepubs/009695399/basedefs/time.h.html

Python のドキュメントでは結構長いあいだ議論されていた → http://bugs.python.org/issue2568

comp.dcom.telecom の Message-ID: <a05v3h$e3a$1@news.tht.net> のメッセージによれば( https://groups.google.com/d/msg/comp.dcom.telecom/Qq0lwZYG_fI/Ttieu9Vu3QIJ )、ANSI C の議論中に認識不足でうっかり入ってしまったものだとのことで、次に示す資料などは関係ない模様である。http://www.mail-archive.com/leapsecs@leapsecond.com/msg00306.html によれば、議論の過程では複数秒のうるう秒がありうるような表現があったらしい。

■内容

日本標準時に「うるう秒」が挿入される2017年1月1日 (日) AM9:00から最大3時間は「117時報サービス」をご利用になった場合、時報に1秒未満のズレが発生致します。

携帯電話に表示される時刻や通話明細に印字する時刻等、その他時刻にズレは発生致しません。

■影響日時

2017年1月1日 (日) AM9:00~AM12:00

2009年の閏秒調整で、NTT東西のひかり電話においては1/100秒ずつ挿入の処理ではなく、午前9時をしめす電子音を2回鳴らすことによって調整がなされた。聴いてみると非常にあっけない。

7月1日あるいは1月1日の午前9時の直前に1秒だけけずるか追加ついかして,世界時に近づける。

東京証券取引所は、下記記事のように、「うるう秒」対策をした上で、さらに関係先に留意事項を通知しています。

午前9時に取引開始の東京証券取引所では、突然1秒が挿入されないように、1秒を午前7時からの2時間(7200秒)に“分散”して調整する。取引に大きな影響はない見込みだが、千分の1秒単位で注文が飛び交うだけに、東証は3月、関係先に留意事項の文書を通知した。

また、米国の主要証券取引機関であるNASDAQに至っては、取引時間内であるにも関わらず、「うるう秒」の発生30分前に全取引を停止するという念の入った対策を行っています。

電波時計は2017年1月1日午前8時59分59秒以降、1秒進んでいる状態になりますが、その後に強制受信を行っていただければ、正確な時刻(日本標準時)に修正できます。また、時計をそのままにしておいても、自動受信(1月2日の午前2時以降)すれば、正確な時刻に修正されます。

秒は0 - 61の整数で表されます。値60および61は、うるう秒のためにだけ、そして実際にうるう秒を正確に追跡するJavaの実装だけで発生します。現在使われているうるう秒の算出法では、2回のうるう秒が同じ分に発生することはきわめてまれですが、この仕様はISO Cによる日付および時刻の規約に従います。

+ Fix localtime misbehavior involving positive leap seconds in a

+ timezone with a UTC offset that is not on a minute boundary.

+ (No such timezone exists in tzdb, luckily.) Without the fix,

+ the timestamp was ambiguous during a positive leap second.