うるう秒のサポート

  • [アーティクル]

この記事では、うるう秒の Microsoft サポートに関する情報を提供します。

適用対象:Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2008 R2 Service Pack 1、Windows 10、バージョン 2004、Windows 10、バージョン 1909、Windows 10、バージョン 1803、Windows 10、バージョン 1709、Windows 7Service Pack 1
元の KB 番号: 2722715

概要

この記事には、うるう秒の Microsoft サポートに関する情報が含まれています。 閏秒は 1 秒の調整であり、その時刻を平均太陽時間 (UT1) に近づけるために、協定世界時 (UTC) に適用される場合があります。

注:

Windows Server 2019 と Windows 10 October 2018 Update では、プラットフォームでうるう秒がサポートされます。 ただし、この記事は、これらの以降のオペレーティング システムには厳密には適用されません。 詳細については、以下を参照してください:

詳細

(1) Windows

OS について
うるう秒処理は、Windows オペレーティング システム (OS) によって個別に処理されません。 たとえば、次の形式の年、月、日付、時刻の情報は、Windows OS ではサポートされていません。

yyyy/mm/dd 08:59:60

したがって、2012/7/1 08:59:60 は、ISO 8601 形式に従って 2012/7/1 09:00:00 として処理されます。

時刻同期サービス (Windows タイム サービス) について
Windows タイム サービスは、NTP サーバーから、Windows タイム サービスをホストするサーバーと同期するダウンレベルのクライアントに Leap Indicator (LI) フラグを通過する場合でも、うるう秒を実装しません。 Windows 時刻同期サービス (W32Time) は閏秒を挿入せず、代わりに通常の時刻同期プロセスを続行します。

アップストリーム NTP サーバー (W32time Server を含む) での閏秒の導入後の短い期間に、そのアップストリーム NTP サーバーと、そのサーバーから同期する W32time クライアントの間で約 1 秒の時間差が発生します。 W32time クライアントは、その後アップストリーム サーバーから時刻を同期するときに、ローカル クロックを修正します。

詳細については、次の Microsoft サポート技術情報 (KB) の記事を参照してください。

909614 Windows タイム サービスが閏秒を処理する方法

さらに、Windows タイム サービスでは、1 秒などの限界時間差が発生するのを常に防ぐことはできません。 オペレーティング システムは、時間の変動を処理するように設計されています。 うるう秒のバリエーションはクリーンに処理され、中断されない実行が可能です。 詳細については、次の KB 記事を参照してください。

939322 高精度環境用に Windows タイム サービスを構成するためのサポート境界

クラスター サービスについて クラスター構成については、OS と同じです。うるう秒処理は実行されません。

(2) SQL Server 2000、2005、2008、2008 R2、2012、および 2014

SQL Serverでは、トランザクションなどの内部操作を管理するために時間データは使用されません。 そのため、閏秒のためにシステム時刻に 1 秒の偏差が発生しても、SQL Server操作には影響しません。 Windows OS と同様に、SQL Serverは閏秒を個別に認識しません。

日付データ型 (datetime など) では、2012/7/1 08:59:60 など、秒の値が 60 に達する形式はサポートされていないことに注意してください。 そのため、うるう秒をサポートする OS で実行されているアプリケーションからSQL Serverへの接続が確立され、OS が日付データ型の列と変数に閏秒 (2 番目の値が 60 のデータ) を設定しようとすると、エラーが返されます。 詳細については、次の「リファレンス情報」セクションを参照してください。

参照情報

[例]閏秒がSQL Serverの日付データ型として処理される場合

create table leap_second(
a int,
b datetime,
)
go
insert into [leap_second] values (1,convert(datetime,'2012/07/01 08:59:60'))
go
select convert(datetime,'2012/07/01 08:59:60')
go
select datediff(day,convert(datetime,'2012/07/01 08:59:60'),getdate())
go
declare @b datetime
set @b='2012/07/01 08:59:60'
go
declare @c time
set @c='08:59:60'
go
declare @d datetime2
set @d='2012/07/01 08:59:60'
go
declare @e datetimeoffset 
set @e='2012/07/01 08:59:60'
go

結果
メッセージ 242、レベル 16、状態 3、行 1
varchar データ型から datetime データ型への変換の結果、値は範囲外に設定されます。
ステートメントは終了しました。

メッセージ 242、レベル 16、状態 3、行 1
varchar データ型から datetime データ型への変換の結果、値は範囲外に設定されます。

メッセージ 242、レベル 16、状態 3、行 1
varchar データ型から datetime データ型への変換の結果、値は範囲外に設定されます。

メッセージ 242、レベル 16、状態 3、行 3
varchar データ型から datetime データ型への変換の結果、値は範囲外に設定されます。

メッセージ 241、レベル 16、状態 1、行 2
文字列から日付と時刻、または 2 つのいずれかに変換中に変換プロセスが失敗しました。

メッセージ 241、レベル 16、状態 1、行 2
文字列から日付と時刻、または 2 つのいずれかに変換中に変換プロセスが失敗しました。

メッセージ 241、レベル 16、状態 1、行 2
文字列から日付と時刻、または 2 つのいずれかに変換中に変換プロセスが失敗しました。

(3) Exchange Server 2003年、2007年、2010年、2013年

Exchange Serverで使用される時間には、システム クロックによって測定される時間と、サービスの開始後の経過時間として計算される時間が含まれます。 システム クロックを使用する処理では、Exchange サーバーはうるう秒を認識せずに動作します。 一方(経過時間が関係する場合)、閏秒の挿入に伴って1秒の差が発生しますが、この偏差は通常の状況でも発生する可能性があります。 Windows OS と同様に、Exchange Serverは軽微な時間変動を処理するように設計されています。 したがって、Exchange Server操作は影響を受けません。

内部操作に加えて、iCalendar 形式のスケジュールは、うるう秒が追加された時刻値を (外部から) 受信できるケースを表します。 ただし、Exchange Serverが iCalendar 形式でスケジュールを受け取る場合、プログラムでは、RFC 5545 に準拠して時刻表記が定義されている形式のみがサポートされます。 閏秒に関しては、秒表記は 060 の範囲でサポートされています。 60 を超える数値が秒の値として指定されている場合、無効な形式として処理され、正しい iCalendar 形式として認識されません。

Outlook では、60 秒は 0 と見なされます。 そのため、2012/07/01 08:59:60 は 2012/07/01 08:59:00 になります。 これは、最大で 1 分の偏差の可能性があることを意味します。 このような場合、メールの受信順序がずれているように見えることがありますが、それ以外の場合は操作に影響しません。

詳細については、次のトピックを参照してください。

2.2.36 [RFC5545] セクション 3.3.12 時刻

(4) インターネット インフォメーション サービス (IIS)

うるう秒は IIS には影響しません。

(5) その他

Windows で実行されているアプリケーションでは、通常、システム クロックが使用されます。 そのため、閏秒を考慮せずに使用できます。

ただし、時間を自分で管理し、閏秒をサポートするアプリケーション、またはうるう秒をサポートする OS で実行されているアプリケーションから Microsoft 製品にアクセスすると、問題が発生する可能性があります。 これは、Microsoft 製品が閏秒を認識しないためです。

さらに、アプリケーションは、単調に増加するためにシステム時間に依存しないようにする必要があります。 代わりに、 GetTickCount64() 関数を使用して現在のティック数を読み取る必要があります。これは、スタートアップからの時間 (ミリ秒単位)。