2

データをエクスポートする場合（rclick db |タスク|スクリプトの生成...）、日時列は次のようにエクスポートされます。

CAST(0xFFFF2E4600000000 AS DateTime)

の上

select CAST(0xFFFF2E4600000000 AS DateTime)

..SQL Server Mgmt Studioで次のようになります：

1753-01-01 00:00:00.000

これ（つまり、ここでは0xFFFF2E4600000000）を別のプログラムで通常の日時に変換する必要があります。

これで、1900年1月1日以降の日付でフォーマットがどのように機能するかがわかりました。

first 4 bytes == the days since 1st Jan 1900
2nd 4 bytes == number of ticks since midnight (each tick is 1/300 of a second).

これは機能しますが、上記の16進数（0xFFFF2E4600000000）が1753-01-01にどのように変換されるかを理解できません。2の補数、1900年から1753年までの日のさまざまな変換など-何も機能しません。それが私に投げかけるグーグルでの検索結果も役に立たない。お知らせ下さい！

更新：

とにかく2の補数と関係があるようです。以下を参照してください。ただし、Pythonシェルではまだ完全には機能しません。

>>> e=1900-1753
>>> e
147
>>> 
>>> e*=365
>>> e
53655
>>> e=e-(1<<32)
>>> e
-4294913641L
>>> hex(e)
'-0xffff2e69L'

これは0xFFFF2E46に近いですが、完全にはありません。何が起きてる？

更新2：

うるう日？

4

1 に答える 1

0

は、私にはよく見えますよ：

declare @Sample as DateTime = '1753-01-01'
select @Sample as 'Sample', Cast( @Sample as VarBinary(8) ) as 'VarBinary',
  DateDiff( day, '1900-01-01', @Sample ) as 'DateDiff',
  Cast( DateDiff( day, '1900-01-01', @Sample ) as VarBinary(4) ) as 'Hex DateDiff'

16進値は符号付き32ビット値として扱われることに注意してください。

質問が「なぜ53,690なのか」の場合 答えは次のとおりです。

; with Years as (
  select 1753 as Year, 0 as LeapYear
  union all
  select Year + 1,
    case
     when ( Year + 1 ) % 400 = 0 then 1
     when ( Year + 1 ) % 100 = 0 then 0
     when ( Year + 1 ) % 4 = 0 then 1
     else 0 end
    from Years
    where Year < 1900 )
  select 147 * 365 + Sum( LeapYear ) as Days from Years
  option ( maxrecursion 0 )
于 2013-01-29T17:20:37.670 に答える