web-dev-qa-db-ja.com

SQL Server 2014は夏時間を考慮していますか？

私のコンピューター/ SQL Server 2014は、UTC時間より5時間遅い東部標準時を使用しています。しかし、次のコードを実行すると、4時間の差が出ます。

CREATE TABLE datetimeoffsetfunction(    
                                    servertime DATETIME2,
                                    utc_servertime DATETIME2,
                                    offset_datetime DATETIMEOFFSET,
                                    switch_offset DATETIMEOFFSET,
                                    to_datetime DATETIMEOFFSET
                                      );

INSERT INTO datetimeoffsetfunction
VALUES (  SYSDATETIME(), 
          SYSUTCDATETIME(), 
          SYSDATETIMEOFFSET(),
          SWITCHOFFSET(  SYSDATETIMEOFFSET(),  '+05:00'),
          TODATETIMEOFFSET( SYSDATETIME(), '+05:00')
          );

The result I got is 

servertime:         2016-07-09 23:59:16.4770556
utc_servertime:     2016-07-10 03:59:16.4770556
offset_datetime:    2016-07-09 23:59:16.4770556 -04:00
switch_offset:      2016-07-10 08:59:16.4770556 +05:00
to_datetime:        2016-07-09 23:59:16.4770556 +05:00

Servertimeは私のシステム時刻であり、夏時間を考慮すると、servertimeとutc_servertimeの差が4時間しかない理由を説明できます。しかし、私はoffset_datetimeが2016-07-09 23：59：16.4770556 -05:であると予期していましたが、SQL Serveが夏時間を考慮しないようになりました。

だから私の質問は、少なくとも2014年以降、夏時間が自動的に考慮されるのはSQL Serverですか？

sql-servert-sqldatetimedatetimezone
5
John Smith

現在自動的に考慮される夏時間は、少なくとも2014年からSQL Serverですか？

いいえ、SQL Server 2014は「DST認識」ではなく、テストでそれが示されていません。

まず、4番目と5番目のテスト（それぞれSWITCHOFFSET( SYSDATETIMEOFFSET(), '+05:00')とTODATETIMEOFFSET( SYSDATETIME(), '+05:00')）は_+05:00_を示しています。

次に、SYSDATETIMEOFFSET()は_-04:00_を表示しています。これは、現在のオフセットがサーバーのTimeZoneの真の違いであるためです（変更しないと、約半年の正確な時刻が表示されません）。 UTC。これは、年間を通じて変化しません。ただし、これはDSTに対応していることを示しています。DSTに対応しているのはOSであり、サーバーのcurrent時間はDSTに基づいて変化します。

DST対応であることは、TimeZonesを切り替えるときに、前の期間のDST日付境界およびの他のTimeZonesを考慮することができることを意味します。そして、これにはTimeZonesの知識が必要です。ただし、SQL Server（少なくともSQL Server 2016より前）にはTimeZonesの概念がありません。オフセットはそれだけです。UTCから特定の時間と分だけ離れています。対照的に、TimeZoneは、特定のオフセットと夏時間を適用した場合（一部のTimeZonesはDSTに参加しない）およびDSTが適用される場合、それらの日付の境界は何ですか（これは法律の問題であり、地域ごとに時間とともに変化します）。

したがって、DST対応であることは、過去の日付を現在のTimeZoneに、または現在のTimeZoneから、またはまたは任意の2つのTimeZone間の任意の日付に変換できることを意味します。サーバーの現在のTimeZoneです。つまり、SQL ServerがDSTに対応している場合は、以下から変換できることを示しています。

  • UTCから東部標準時（サーバーの現在のTimeZone）へ、20年前の年の任意の日付で、その間に米国でDST日付境界が変更されていても、正しい時刻を取得します。ただし、現在のオフセット（_-04:00_）しか計算できず、そのオフセットが_-05:00_になる時期を特定する方法がないため、計算できません。
  • 任意の日付について、東部以外のTimeZoneから他の東部以外のTimeZoneへ、正しい時刻を取得します。これは不可能です。特定の年の特定の日付が正しく調整されるように、これらの日付境界の履歴シフトを含め、どのTimeZoneがどの日付に対してどのオフセットであるかを詳細に示すTimeZonesのチャートがないためです。

詳細といくつかの例

上記のように、タイムゾーンオフセットはタイムゾーンではなく、単にタイムゾーンのプロパティです。つまり、「US/Eastern」（別名「America/New_York」）タイムゾーン（つまり、EST/EDT）は_-04:00_として識別されず、_-05:00_として識別されるだけです。東と西に境界があり、ベースオフセットが_-05:00_であり、夏時間に参加しているため、オフセット-_+01:00_-と特定の開始日があるエリアです。そして、そのDSTオフセットをいつ適用するかの終了日。この情報は TimeZoneDB.com で確認できます。

このタイムゾーン情報のメインデータベースは、Internet Assigned Names Authority（IANA）によって管理されており、次の場所にあります。

http://www.iana.org/time-zones

タイムゾーン情報は、個々の政府によって決定されます。 DSTに参加している国と参加していない国があります。さまざまな国/州内の一部の都市は、親地域のルールをオプトインまたはオプトアウトしています。世界のさまざまな開始日と終了日（少なくとも2016年）のグラフについては、TimeAndDate.comの 世界の夏時間2016 のページを参照してください。例外を含む詳細については、 東部時間（ET） のページを確認してください。

また、特定の領域がDSTを監視するかどうか、また監視する場合、データの境界とは何かが、時間とともに変化します。たとえば、米国では、DSTの開始日と終了日は2005年後半に変更され、2007年から有効になります： 2005年に変更された米国の夏時間 。つまり、現在のルールが_+01:00_オフセットを3月13日から11月6日の間にESTに適用することがわかっている場合でも、DATETIMEの_2006-11-02 18:00:00_の値をUTCからET、あなたは_2006-11-02 14:00:00_を取得しますが、これは間違っています。2006年の夏時間は10月28日に終了し、正しい東部標準時が_2006-11-02 13:00:00_になったためです。

ここで私のDBA.StackExchangeの回答の追加説明： 特定の日時のタイムゾーンを確認する方法

SQL Server 2005-2014でのDST（およびタイムゾーン間の変換）の処理方法

DST認識を適切に処理し、異なるタイムゾーン間で変換するために知っている2つの主な方法は次のとおりです。

  1. Matt Johnson の SQL Serverタイムゾーンサポート プロジェクト：

    これは純粋なT-SQLアプローチです。上にリンクされているメインページの下部にあるReadMe（つまり、プロジェクト名）を参照してください。 ConvertZone関数とSwitchZone関数に注意してください。単なるオフセットではなく、実際のタイムゾーン！

    また、次のように記載されていることにも注意してください。

    Microsoft SQL Server 2008 R2以降（Azure SQLデータベースを含む）がサポートされています

  2. SQLCLR：

    DateTime.ToLocalTime と DateTime.ToUniversalTime を使用すると、サーバーのローカルタイムゾーンとUTC間の相互変換がかなり簡単になります。これは、SQL Server 2005以降で機能します。

    TimeZone.ToLocalTime ページに次の警告が表示されるため、同じ名前のメソッドを持つTimeZoneclassには近づかないでください。

    ToLocalTimeメソッドは、ローカルタイムゾーンの現在の夏時間調整ルールのみを認識します。その結果、最新の調整ルールが有効な期間のみ、特定のUTC時間に対応する現地時間を正確に返すことが保証されます。時刻が以前の調整ルールの対象であった過去の日付と時刻の値である場合、不正確な結果を返す可能性があります。

    タイムゾーン間の変換は少しトリッキーです。これを処理する組み込みの.NETクラスがありますが、呼び出し側のアセンブリをUNSAFEとしてマークする必要があります--MayLeakOnAbort（メモリリーク）。人々はこのクラスを使用しており、メソッドをひどく頻繁に呼び出さない場合は問題ないかもしれません。しかし、少なくとも1つのケースで、これを多数（数十万または数百万）の行にわたって実行すると、メモリリークのように見えるものを報告したケースが1つありました。

    ToLocalTimeクラスの安全なToUniversalTimeおよびDateTimeメソッドについて：これらのプリコンパイルされたバージョンは、作成した SQL＃ SQLCLRライブラリで使用できます。ただし、フルバージョンのみ（無料バージョンでは不可）。これらの2つの方法が機能することを示すために、2007年以降に米国で発生した日付境界の変更に関する上記の状況を検討してください。

    _SELECT SQL#.Date_ToLocalTime('2007-10-31 20:23:45') AS [CurrentRule],
       SQL#.Date_ToLocalTime('2006-10-31 20:23:45') AS [PriorRule];
_

    戻り値：

    _CurrentRule                PriorRule
2007-10-31 16:23:45.000    2006-10-31 15:23:45.000
_
7
Solomon Rutzky

グーグル経由で来た。何よりもまず優れた投稿であるマットジョンソンのSQL Serverタイムゾーンサポートプロジェクトの推奨により、ソロモンルッツキーの投稿を見ていました。彼のページによると、DSTはMSSQL 2016で完全にサポートされています

https://blogs.technet.Microsoft.com/dataplatforminsider/2015/11/30/sql-server-2016-community-technology-preview-3-1-is-available/

https://docs.Microsoft.com/en-us/sql/t-sql/queries/at-time-zone-transact-sql

それは次のように簡単です：

select getdate() at time zone 'Mountain Standard Time'

サポートされているすべての異なるゾーンへのリンクは次のとおりです。

https://technet.Microsoft.com/en-us/library/cc749073（v = ws.10）.aspx

1
silver