アカウント名:
パスワード:
日付時刻型もうるう秒対応するのかな?
.Net Framworkはかなり互換性には 配慮している [ufcpp.net]からうるう秒対応の日付時刻型をも一個作ると思う。既にDateTimeに時差情報の追加したDateTimeOffsetという型があるし。既存のいろんなところでDateTime使っているけどそれは多分そのままかな。厄介なのがうるうDateTimeとDateTimeへの変換はおそらくどちらも安全ではないって事。うるう秒はDateTimeにすると表現できないし、DateTimeは内部ではInt64を使っているらしいから仮
おそらく、文字列への変換と、文字列からの変換に修正が入るだけです。レジストリに閏秒の一覧表を登録して、変換するときに調整するだけの話になるでしょう。内部形式のInt64のデータには何も変更がないでしょう。
どうやっても既存実装に何の影響もなく収まる事はないから、そこは敢えて捻らないんじゃないかな。Int64データが同値であっても、システム側のうるう秒定義によって、その値が意味する時刻がずれるようになるんじゃないかと。
今の.NETはマルチプラットフォームだからOSと密結合なのは無理。そもそもうるう秒は秒が増えるわけだから60秒の間をInt64では表現できない。もちろん実際に経過した秒数としてはうるう秒なしでは嘘になるわけだが、それで齟齬が生じる事はあまりない。問題はOSが対応してしまった事で例えば60秒を翌0秒とする事で時間が遡るか停止する事になるわけでそれをどうするかと。手っ取り早いのはDateTimeOffsetにbool?型のIsLeapSecondみたいなのを追加した構造体を作って時間比較では60秒を特別扱いする事だけど問題はある。具体的にはある秒からの経過時間が閏秒後に減るって事。経過時間も正しく測れない。でもUnix時間だって同じ事なわけでそれで動いてるんだから許容できるかもしれない。では閏秒を含んだ経過時間による表現を追加すればいいかといえばそうはいかない。初回アクセスでOSのうるう秒履歴を取得すればいいがWindows以外でも対応しないといけないし(Xamarinはそこそこ使われてる)(未対応を返したっていいけど内部表現がずれる)、未来の時間を正しく表現できないのも厄介。スケジュール表が勝手に一秒ずれて前日になったりしたら困る。他には過去のうるう秒履歴を各インスタンスが持ってるってのもありかもしれない。メモリを食うが仕方ない。まぁ一秒遡るのは仕方がないとして無視すると思うけど、Win32APIのラッパーみたいなのではきちんと対応するはずで、そこではどんなDateTimeの拡張みたいなのを作るのかはちょっと期待。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
.Net FrameworkやSQL Serverはどうなる? (スコア:2)
日付時刻型もうるう秒対応するのかな?
Re: (スコア:0)
.Net Framworkはかなり互換性には 配慮している [ufcpp.net]からうるう秒対応の日付時刻型をも一個作ると思う。
既にDateTimeに時差情報の追加したDateTimeOffsetという型があるし。
既存のいろんなところでDateTime使っているけどそれは多分そのままかな。
厄介なのがうるうDateTimeとDateTimeへの変換はおそらくどちらも安全ではないって事。
うるう秒はDateTimeにすると表現できないし、
DateTimeは内部ではInt64を使っているらしいから仮
Re: (スコア:0)
おそらく、文字列への変換と、文字列からの変換に修正が入るだけです。レジストリに閏秒の一覧表を登録して、変換するときに調整するだけの話になるでしょう。
内部形式のInt64のデータには何も変更がないでしょう。
Re: (スコア:0)
Re: (スコア:0)
どうやっても既存実装に何の影響もなく収まる事はないから、そこは敢えて捻らないんじゃないかな。
Int64データが同値であっても、システム側のうるう秒定義によって、その値が意味する時刻がずれるようになるんじゃないかと。
Re:.Net FrameworkやSQL Serverはどうなる? (スコア:0)
今の.NETはマルチプラットフォームだからOSと密結合なのは無理。
そもそもうるう秒は秒が増えるわけだから60秒の間をInt64では表現できない。
もちろん実際に経過した秒数としてはうるう秒なしでは嘘になるわけだが、それで齟齬が生じる事はあまりない。
問題はOSが対応してしまった事で例えば60秒を翌0秒とする事で時間が遡るか停止する事になるわけでそれをどうするかと。
手っ取り早いのはDateTimeOffsetにbool?型のIsLeapSecondみたいなのを追加した構造体を作って時間比較では60秒を特別扱いする事だけど問題はある。
具体的にはある秒からの経過時間が閏秒後に減るって事。経過時間も正しく測れない。
でもUnix時間だって同じ事なわけでそれで動いてるんだから許容できるかもしれない。
では閏秒を含んだ経過時間による表現を追加すればいいかといえばそうはいかない。初回アクセスでOSのうるう秒履歴を取得すればいいがWindows以外でも対応しないといけないし(Xamarinはそこそこ使われてる)(未対応を返したっていいけど内部表現がずれる)、未来の時間を正しく表現できないのも厄介。スケジュール表が勝手に一秒ずれて前日になったりしたら困る。
他には過去のうるう秒履歴を各インスタンスが持ってるってのもありかもしれない。メモリを食うが仕方ない。
まぁ一秒遡るのは仕方がないとして無視すると思うけど、Win32APIのラッパーみたいなのではきちんと対応するはずで、そこではどんなDateTimeの拡張みたいなのを作るのかはちょっと期待。