アカウント名:
パスワード:
日付時刻型もうるう秒対応するのかな?
そりゃ対応するでしょ。そして「60」秒が返ってきてそこら中で例外発生よ
秒が60を返してきただけで例外が発生するようなことってあるか?
そのへんの言語仕様も変えちゃうんじゃないかなーでもって8:00=on&&on=8:59:59みたいな書き方をしていると8:59:60にヤッたことが全部漏れると
世の中「んな馬鹿な」と思う条件で問題が起きるんですよ!
疲れていたとか検討する時間が不十分だったとかはんな場かなと思う条件?//==と=を間違えたことはあるし==と===を間違えたこともある
例えばint data[60];で60秒分の配列用意してあったら、data[60]に代入しようとして死亡。
日付時刻型クラスがどうなるかですね。ログや通信データに08:59:60が有った時にパースで落ちなければ良いですが。他にも加算、減算で60の扱いがどうなるとか。
メーラーとかブラウザとかヘッダの時刻が正しく取り扱いしてくれるか再確認が必要かも。
今回Windows Serverがこうなりましたけど、AzureやAWSとかの米国にあるLinuxサーバーやサービスとかもうるうをぶっこんでんでくる可能性があるって事で対岸の火事ではいられない可能性が。
manページには、struct tmのtm_secは、閏秒のために「60」が設定される可能性があると明記してあるので、システムとして想定済みではあるんでは。
PowerShell> ([datetime]'2018/07/23'-[datetime]'2018/07/22').ToString()が、普通は'1.00:00:00'になるんだけど、うるう秒跨ぐ時はどうなるんだろうなー。やっぱ'1.00:00:01'だろうな、きもいなーw。2017年とか過去のうるう秒も存在した値で返るようになんのかな。
規制強化が理由だから入るでしょうね。「一分は60秒」が崩れるってキツイなぁ。
クラスはプロパティオーバーロード追加かなぁ?デフォルトどうする?で揉めそう。。
これ、混在せざるを得ない辺りが厄介ですね。接続先が違う時間軸あり得るとかシャレにならない。
「一分は60秒」が崩れるってキツイなぁ
表現が難しいのだけど、うるう秒がはいったとしても、時間としての1分は60秒のままだよ。あくまで、うるう秒がある場合にうるう秒の情報がないと、ある時刻と時刻の間の時間が不定になる、というだけ。
何いってんの?一日の秒数は変わるのよ。こんなんばかりだとそら混乱するわな。
時間単位としての1日は86400秒で不変です。「暦日の長さ」が(時間単位としての)1日(=86400秒)でなくなるだけです。
うるう秒の挿入に関係なく「暦日の長さ」は変動するものです。というより変動の結果としてうるう秒が挿入されるのです。
いや、内部的な話をしているので。
例えば、DateTime.AddDays [microsoft.com]メソッドは、日付・時刻インスタンスに指定された日数を加算するものです。が、これが内部的にはまさに「時間単位としての1日」*日数を足しているだけなんですよ。(定数MillisPerDay*valueを足しているだけ)なので、DateTimeクラスがうるう秒対応した場合、「うるう秒が入る日にAddDays(1)をしても、日付が変わらない」ということが起き得ます。
例えば、次の日の日付を取得するためにAddDays(1)を実行しているコードは非常に多いです。(.NET Frameworkの中にも、そうしたコードがたくさんある)それらは、うるう秒対応で軒並み誤動作するようになります。
OSSの中には、内部処理をUNIX Timeで実装しているようなものもたくさんあるだろうし、そういう場合に、その辺の変換がどうなるのかは気になる。
.Net Framworkはかなり互換性には 配慮している [ufcpp.net]からうるう秒対応の日付時刻型をも一個作ると思う。既にDateTimeに時差情報の追加したDateTimeOffsetという型があるし。既存のいろんなところでDateTime使っているけどそれは多分そのままかな。厄介なのがうるうDateTimeとDateTimeへの変換はおそらくどちらも安全ではないって事。うるう秒はDateTimeにすると表現できないし、DateTimeは内部ではInt64を使っているらしいから仮
おそらく、文字列への変換と、文字列からの変換に修正が入るだけです。レジストリに閏秒の一覧表を登録して、変換するときに調整するだけの話になるでしょう。内部形式のInt64のデータには何も変更がないでしょう。
そのあたりは新元号対応と同じでしょうね。
内部データに手を入れないならParse()で60秒を翌0秒とみなすだけで十分かと。
どうやっても既存実装に何の影響もなく収まる事はないから、そこは敢えて捻らないんじゃないかな。Int64データが同値であっても、システム側のうるう秒定義によって、その値が意味する時刻がずれるようになるんじゃないかと。
今の.NETはマルチプラットフォームだからOSと密結合なのは無理。そもそもうるう秒は秒が増えるわけだから60秒の間をInt64では表現できない。もちろん実際に経過した秒数としてはうるう秒なしでは嘘になるわけだが、それで齟齬が生じる事はあまりない。問題はOSが対応してしまった事で例えば60秒を翌0秒とする事で時間が遡るか停止する事になるわけでそれをどうするかと。手っ取り早いのはDateTimeOffsetにbool?型のIsLeapSecondみたいなのを追加した構造体を作って時間比較では60秒を特別扱いする事だけど問題はある。具体的にはある秒からの経過時間が閏秒後
Ticksの問題もあるからそんな単純ではない。
きっと、レジストリに閏秒の一覧表でも登録するようになるのだろう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
.Net FrameworkやSQL Serverはどうなる? (スコア:2)
日付時刻型もうるう秒対応するのかな?
Re:.Net FrameworkやSQL Serverはどうなる? (スコア:4, 興味深い)
そりゃ対応するでしょ。そして「60」秒が返ってきてそこら中で例外発生よ
Re: (スコア:0)
秒が60を返してきただけで例外が発生するようなことってあるか?
Re: (スコア:0)
そのへんの言語仕様も変えちゃうんじゃないかなー
でもって8:00=on&&on=8:59:59
みたいな書き方をしていると8:59:60にヤッたことが全部漏れると
Re: (スコア:0)
世の中「んな馬鹿な」と思う条件で問題が起きるんですよ!
Re: (スコア:0)
疲れていたとか検討する時間が不十分だったとかはんな場かなと思う条件?
//==と=を間違えたことはあるし==と===を間違えたこともある
Re: (スコア:0)
例えばint data[60];で60秒分の配列用意してあったら、data[60]に代入しようとして死亡。
Re: (スコア:0)
日付時刻型クラスがどうなるかですね。
ログや通信データに08:59:60が有った時にパースで落ちなければ良いですが。
他にも加算、減算で60の扱いがどうなるとか。
メーラーとかブラウザとかヘッダの時刻が正しく取り扱いしてくれるか再確認が必要かも。
今回Windows Serverがこうなりましたけど、AzureやAWSとかの米国にあるLinuxサーバーやサービスとかもうるうをぶっこんでんでくる可能性があるって事で対岸の火事ではいられない可能性が。
Re:.Net FrameworkやSQL Serverはどうなる? (スコア:2)
manページには、struct tmのtm_secは、閏秒のために「60」が設定される可能性があると明記してあるので、システムとして想定済みではあるんでは。
Re: (スコア:0)
PowerShell> ([datetime]'2018/07/23'-[datetime]'2018/07/22').ToString()
が、普通は'1.00:00:00'になるんだけど、うるう秒跨ぐ時はどうなるんだろうなー。
やっぱ'1.00:00:01'だろうな、きもいなーw。
2017年とか過去のうるう秒も存在した値で返るようになんのかな。
Re: (スコア:0)
規制強化が理由だから入るでしょうね。
「一分は60秒」が崩れるってキツイなぁ。
クラスはプロパティオーバーロード追加かなぁ?デフォルトどうする?で揉めそう。。
これ、混在せざるを得ない辺りが厄介ですね。接続先が違う時間軸あり得るとかシャレにならない。
Re: (スコア:0)
「一分は60秒」が崩れるってキツイなぁ
表現が難しいのだけど、うるう秒がはいったとしても、時間としての1分は60秒のままだよ。
あくまで、うるう秒がある場合にうるう秒の情報がないと、ある時刻と時刻の間の時間が不定になる、というだけ。
Re: (スコア:0)
何いってんの?一日の秒数は変わるのよ。
こんなんばかりだとそら混乱するわな。
Re: (スコア:0)
時間単位としての1日は86400秒で不変です。
「暦日の長さ」が(時間単位としての)1日(=86400秒)でなくなるだけです。
うるう秒の挿入に関係なく「暦日の長さ」は変動するものです。
というより変動の結果としてうるう秒が挿入されるのです。
Re: (スコア:0)
いや、内部的な話をしているので。
例えば、DateTime.AddDays [microsoft.com]メソッドは、日付・時刻インスタンスに指定された日数を加算するものです。
が、これが内部的にはまさに「時間単位としての1日」*日数を足しているだけなんですよ。
(定数MillisPerDay*valueを足しているだけ)
なので、DateTimeクラスがうるう秒対応した場合、「うるう秒が入る日にAddDays(1)をしても、日付が変わらない」ということが起き得ます。
例えば、次の日の日付を取得するためにAddDays(1)を実行しているコードは非常に多いです。
(.NET Frameworkの中にも、そうしたコードがたくさんある)
それらは、うるう秒対応で軒並み誤動作するようになります。
Re: (スコア:0)
OSSの中には、内部処理をUNIX Timeで実装しているようなものもたくさんあるだろうし、そういう場合に、その辺の変換がどうなるのかは気になる。
Re: (スコア:0)
.Net Framworkはかなり互換性には 配慮している [ufcpp.net]からうるう秒対応の日付時刻型をも一個作ると思う。
既にDateTimeに時差情報の追加したDateTimeOffsetという型があるし。
既存のいろんなところでDateTime使っているけどそれは多分そのままかな。
厄介なのがうるうDateTimeとDateTimeへの変換はおそらくどちらも安全ではないって事。
うるう秒はDateTimeにすると表現できないし、
DateTimeは内部ではInt64を使っているらしいから仮
Re: (スコア:0)
おそらく、文字列への変換と、文字列からの変換に修正が入るだけです。レジストリに閏秒の一覧表を登録して、変換するときに調整するだけの話になるでしょう。
内部形式のInt64のデータには何も変更がないでしょう。
Re: (スコア:0)
そのあたりは新元号対応と同じでしょうね。
Re: (スコア:0)
内部データに手を入れないならParse()で60秒を翌0秒とみなすだけで十分かと。
Re: (スコア:0)
Re: (スコア:0)
どうやっても既存実装に何の影響もなく収まる事はないから、そこは敢えて捻らないんじゃないかな。
Int64データが同値であっても、システム側のうるう秒定義によって、その値が意味する時刻がずれるようになるんじゃないかと。
Re: (スコア:0)
今の.NETはマルチプラットフォームだからOSと密結合なのは無理。
そもそもうるう秒は秒が増えるわけだから60秒の間をInt64では表現できない。
もちろん実際に経過した秒数としてはうるう秒なしでは嘘になるわけだが、それで齟齬が生じる事はあまりない。
問題はOSが対応してしまった事で例えば60秒を翌0秒とする事で時間が遡るか停止する事になるわけでそれをどうするかと。
手っ取り早いのはDateTimeOffsetにbool?型のIsLeapSecondみたいなのを追加した構造体を作って時間比較では60秒を特別扱いする事だけど問題はある。
具体的にはある秒からの経過時間が閏秒後
Re: (スコア:0)
Ticksの問題もあるからそんな単純ではない。
Re: (スコア:0)
きっと、レジストリに閏秒の一覧表でも登録するようになるのだろう。