うるう秒のサポート

この記事では、うるう秒の 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 7 Service Pack 1
元の KB 番号:   2722715

概要

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

注意

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

詳細情報

(1) Windows

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

yyyy/mm/dd 08:59:60

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

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

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

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

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

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

939322のサポート境界を使用して、Windowsのタイム サービスを構成します。

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

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

SQL Server、トランザクションなどの内部操作を管理するために時間データを使用しない場合。 したがって、うるう秒のためにシステム時間に 1 秒のずれが発生した場合でも、システム操作SQL Serverしません。 OS と同様Windows、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 秒の差が発生しますが、通常の状況でもこのずれが発生する可能性があります。 OS と同様Windows、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 Time

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

うるう秒は IIS では効果がありません。

(5) その他

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

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

さらに、アプリケーションは、単調に増加するシステム時間に依存する必要があります。 代わりに 、GetTickCount64() 関数を使用して現在の目盛数を読み取る必要があります。これは、起動からミリ秒単位の時間です。