アカウント名:
パスワード:
DateTime.ToString();は実行環境のカルチャで出力変わるから日本じゃ機能しない…。ただDD/MM/YYとMM/DD/YYの両方対応してるし、mm/ss/HHみたいな順番でも機能するのは優しい。ともかくDateTimeの比較にToString();はしない方が良い。doubleですら危険。
日本だとこうだね＞"2022/01/09 12:00:00"
うんにゃ、厳密には違うよ。引数なしのToStringは、[地域設定]で設定された形式（短い形式のほう）になる。日本では初期値がそうなっているけど、変更も可能。
なので、「日本では"2022/01/09 12:00:00"」と思い込むと痛い目に合う。
そうそう。24時間表記が気に入らなくてAM/PM表示するようにしてたりとか、ゼロフィル/ゼロサプレスしてたりね。
日本だと和暦使うやつも多いでしょ。
ええ、テスト環境は和暦にしてます。ものの見事に動作しないものばかりですよ。オフショアに派遣だけででなく自社のやつまでみんな文字列にしたがる。
WindowsのC++ソフトだけど、日付と時間を取得する時は、基本的に、日付と時間のフォーマットを"yyyy/mm/dd hh:mm:ss"に変更してToStringしてるなぁ...そうすれば、PCの設定関係ないし。
OSの設定を変えるもよしコードで現在のカルチャを変えるもよしですね
目的を忘れて「ローカルタイムは地域に依存するから使うべきではない、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に変換しないといけないので。
規則が変わったときは規則変更に対応しつつ変更への対応が済んでるかどうかも記録せにゃならん…
見事にそのバグを踏み抜いた日本のCOCOAへの皮肉だったりして。
つまり、自称有志の方の中にMSの人がいたという事かもね
自称有志が作ってたのはCOCOAじゃなくてCOVID-19Radar
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
おま国 (スコア:0)
DateTime.ToString();は実行環境のカルチャで出力変わるから日本じゃ機能しない…。
ただDD/MM/YYとMM/DD/YYの両方対応してるし、mm/ss/HHみたいな順番でも機能するのは優しい。
ともかくDateTimeの比較にToString();はしない方が良い。doubleですら危険。
Re: (スコア:0)
日本だとこうだね＞"2022/01/09 12:00:00"
Re:おま国 (スコア:1)
うんにゃ、厳密には違うよ。
引数なしのToStringは、[地域設定]で設定された形式（短い形式のほう）になる。
日本では初期値がそうなっているけど、変更も可能。
なので、「日本では"2022/01/09 12:00:00"」と思い込むと痛い目に合う。
Re: (スコア:0)
そうそう。24時間表記が気に入らなくてAM/PM表示するようにしてたりとか、ゼロフィル/ゼロサプレスしてたりね。
Re: (スコア:0)
日本だと和暦使うやつも多いでしょ。
ええ、テスト環境は和暦にしてます。
ものの見事に動作しないものばかりですよ。
オフショアに派遣だけででなく自社のやつまでみんな文字列にしたがる。
Re: (スコア:0)
WindowsのC++ソフトだけど、日付と時間を取得する時は、基本的に、日付と時間のフォーマット
を"yyyy/mm/dd hh:mm:ss"に変更してToStringしてるなぁ...
そうすれば、PCの設定関係ないし。
Re: (スコア:0)
OSの設定を変えるもよしコードで現在のカルチャを変えるもよしですね
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)
規則が変わったときは規則変更に対応しつつ変更への対応が済んでるかどうかも記録せにゃならん…
Re: (スコア:0)
見事にそのバグを踏み抜いた日本のCOCOAへの皮肉だったりして。
Re: (スコア:0)
つまり、自称有志の方の中にMSの人がいたという事かもね
Re: (スコア:0)
自称有志が作ってたのはCOCOAじゃなくてCOVID-19Radar