アカウント名:
パスワード:
DateTime.ToString();は実行環境のカルチャで出力変わるから日本じゃ機能しない…。ただDD/MM/YYとMM/DD/YYの両方対応してるし、mm/ss/HHみたいな順番でも機能するのは優しい。ともかくDateTimeの比較にToString();はしない方が良い。doubleですら危険。
目的を忘れて「ローカルタイムは地域に依存するから使うべきではない、UTCを使え」とかやりすぎないように注意
ユーザーへの表示とユーザーからの入力はロケールにお任せで内部的にはUTCとかUNIXエポックタイム使うのが正解だと思いますが。サマータイムとかそのへんは別として。UTCじゃねぇGMTだって苦情も別として。
過去の時刻はおおむねUTCでいいけど、未来の時刻を安易にUTCで統一しちゃダメだよ(要件にもよるが)。さもないと予定の日時までにタイムゾーンやサマータイムの規則が変わると時刻がずれるスケジューラーアプリとかができてしまう。
それこそUTCにしないとダメだろ。タイムゾーン＋時刻でもてってか？
> それこそUTCにしないとダメだろ。
なんで? 来年の9:00(JST)から会議を予約→0:00 UTCで記録→突然日本にサマータイム導入→会議開始は10:00(JDT)?→1時間遅刻ってなっちゃうでしょ。(繰り返すが要件にもよる。地球の裏側とオンライン会議する予定だったらタイムゾーンに依存しないほうが望ましいだろう。でもその場合予定時刻の入力自体を最初からUTCか何かにしないと困るよね)
> タイムゾーン＋時刻でもてってか？
そうだよ。それも+09:00とかじゃなくてAsia/Tokyoとかで持たないとダメ。
> Asia/Tokyoとかで持たないとダメ。
ロシアみたいにタイムゾーンが増えたり減ったりするとこれでも対応できないな。要するに日本人の大半が思ってるような「9:00足したり引いたりするだけだろ」とかいう考えで「タイムゾーン不明な時刻」を安易にUTCに変換するとかんたんに落とし穴にハマる。
それはJDTでは10:00開始の会議だろうが。# 夏時間になって時刻が後ろにずれるのも斬新だけど。夏時間の切り替え時刻を01:00として01:00に予定を入れるとする。夏時間になる時はローカルでは01:00が二回くるので他のタイムゾーンだと前後どちらかわからず変換できない。終わる時はローカルでは存在しない時間となってしまう。
ちなIN/OUT以外でUTCで処理しちゃいけないのはdateとdatetimeを日付部分で比較する場合。dateは時差なんて関係ないのでタイムゾーンを考慮してdatetimeをdateに変換しないといけないので。
規則が変わったときは規則変更に対応しつつ変更への対応が済んでるかどうかも記録せにゃならん…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
おま国 (スコア:0)
DateTime.ToString();は実行環境のカルチャで出力変わるから日本じゃ機能しない…。
ただDD/MM/YYとMM/DD/YYの両方対応してるし、mm/ss/HHみたいな順番でも機能するのは優しい。
ともかくDateTimeの比較にToString();はしない方が良い。doubleですら危険。
Re: (スコア:0)
目的を忘れて「ローカルタイムは地域に依存するから使うべきではない、UTCを使え」とかやりすぎないように注意
Re: (スコア:0)
ユーザーへの表示とユーザーからの入力はロケールにお任せで内部的にはUTCとかUNIXエポックタイム使うのが正解だと思いますが。
サマータイムとかそのへんは別として。UTCじゃねぇGMTだって苦情も別として。
Re:おま国 (スコア:0)
過去の時刻はおおむねUTCでいいけど、未来の時刻を安易にUTCで統一しちゃダメだよ(要件にもよるが)。さもないと予定の日時までにタイムゾーンやサマータイムの規則が変わると時刻がずれるスケジューラーアプリとかができてしまう。
Re: (スコア:0)
それこそUTCにしないとダメだろ。
タイムゾーン＋時刻でもてってか？
Re: (スコア:0)
> それこそUTCにしないとダメだろ。
なんで? 来年の9:00(JST)から会議を予約→0:00 UTCで記録→突然日本にサマータイム導入→会議開始は10:00(JDT)?→1時間遅刻
ってなっちゃうでしょ。(繰り返すが要件にもよる。地球の裏側とオンライン会議する予定だったらタイムゾーンに依存しないほうが望ましいだろう。でもその場合予定時刻の入力自体を最初からUTCか何かにしないと困るよね)
> タイムゾーン＋時刻でもてってか？
そうだよ。それも+09:00とかじゃなくてAsia/Tokyoとかで持たないとダメ。
Re: (スコア:0)
> Asia/Tokyoとかで持たないとダメ。
ロシアみたいにタイムゾーンが増えたり減ったりするとこれでも対応できないな。要するに日本人の大半が思ってるような「9:00足したり引いたりするだけだろ」とかいう考えで「タイムゾーン不明な時刻」を安易にUTCに変換するとかんたんに落とし穴にハマる。
Re: (スコア:0)
それはJDTでは10:00開始の会議だろうが。
# 夏時間になって時刻が後ろにずれるのも斬新だけど。
夏時間の切り替え時刻を01:00として01:00に予定を入れるとする。
夏時間になる時はローカルでは01:00が二回くるので他のタイムゾーンだと前後どちらかわからず変換できない。
終わる時はローカルでは存在しない時間となってしまう。
ちなIN/OUT以外でUTCで処理しちゃいけないのはdateとdatetimeを日付部分で比較する場合。
dateは時差なんて関係ないのでタイムゾーンを考慮してdatetimeをdateに変換しないといけないので。
Re: (スコア:0)
規則が変わったときは規則変更に対応しつつ変更への対応が済んでるかどうかも記録せにゃならん…