本当の問題よりも好奇心から。今日質問が出てきましたが、Accessと以前のSQL Serverアプリで1899-12-30が「デフォルト」の日付とゼロの日付として使用されているのを見ました。なぜだろうと思った-それはどこから来たのか、なぜ1899-12-31が使われないのか?
1900年がうるう年である(またはふりをした)と思われるというバグがあった当時のLotus 1-2-3との互換性を維持。
説明は長すぎて引用できませんが、好奇心のために、ここにいくつかの抜粋があります。
1900年はうるう年ではありませんでした。
「Excelのバグです!」私は叫んだ。
「まあ、そうでもない」とエドは言った。 「Lotus 123ワークシートをインポートできるようにする必要があるため、この方法で行う必要がありました。」
「それで、それはLotus 123のバグですか?」
「そうですが、おそらく意図的なものです。Lotusは640Kに収まる必要がありました。これは、それほど多くのメモリではありません。1900を無視すると、右端の2ビットがゼロです。これは本当に速くて簡単です。ロータスの人たちはおそらく過去2か月間は問題がないと考えていました。ベーシックの人はこの2か月についてアナルになりたかったので、 1日前の時代。」
実際には、この数は実際の日数よりも1大きくなります。これは、Excelが1900-Feb-29の日付が存在するかのように動作するためです。それはしませんでした。 1900年はうるう年ではありませんでした(2000年はうるう年です)。 Excelでは、1900-Feb-28の翌日は1900-Feb-29です。実際には、1900年2月28日の翌日は1900年3月1日でした。これは「バグ」ではありません。実際、それは仕様によるものです。 Excelは、Lotus 123のバグであったため、このように機能します。Excelが導入されたとき、123には、スプレッドシートソフトウェアのほぼすべての市場があります。マイクロソフトは、完全に互換性を保つために、ロータスのバグを継続することを決定しました。 123からExcelに切り替えたユーザーは、データを変更する必要はありません。 1900年3月1日以降のすべての日付であれば、これは問題になりません。
私の知る限り、日付タイプは「古いSQL Server」には存在しませんでした。これは、0001/01/01に対応するゼロの日付値を持つSQL Server 2008で導入されました。
select cast(0x000000 as date),cast(CONVERT(date, '0001/01/01') as varbinary(max))
---------- --------
--0001-01-01 0x000000
質問の発言は意味がありません。日付タイプが「古いSQL Server」に存在していたとしたら、SQL Server 2008の日付タイプの下位互換性が壊れていることを意味していました。
未定義または誤って定義された用語を使用して、質問に回答する(および投稿に賛成する)意味はありません。
SQL Serverは、定義されたタイムソースに接続できない場合、この日付をデフォルトとして返すようです。
これは、バイオメトリック時間出席システムが実行中/使用中のクラスターフェールオーバーインシデント中に発生しました。
ローカルクロック操作を無効にするために、誰かが出勤します。SQLクラスターインスタンスに何時か尋ねます。
有効なアクティブタイムソースを取得できず、この日付を返します。
私の回避策は、GetServerTime
Subでこの日付を確認し、この「デフォルト」が返された場合はローカルPC時間を使用することで簡単です。
SQL 2000/2005/2008でこれを見てきましたが、すべてADOおよびVB6を介して)。