アカウント名:
パスワード:
でもサマータイムは、これから新規に作るソフトウェアへのバグ混入率が定常的に増えるという影響が出そうです。工場のプラントのように日付をそもそも使わないようにしている奴は大丈夫だけど。 y2kのときに2000年がうるう年かどうかのロジックが間違っているソフトが結構発見されましたが、サマータイム処理はもっと難しいとおもう。
ところで、年月日時分秒の文字列から時刻値を得る関数って、サマータイムのときはどうなるんですかね。サマータイムが終わる日って、23:59:→00:00→00:01・・・・・→00:59→00:00→00:01というふうに時刻が推移するとおもうんだけど。0時~0:59が繰り返されて一意に定まらないんぢゃぁ??。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
絶対反対その2 (スコア:5, すばらしい洞察)
Y2Kの時も真っ青なアップデートの嵐になるだろうし。
-- gonta --
"May Macintosh be with you"
Re:絶対反対その2 (スコア:2, 興味深い)
でもサマータイムは、これから新規に作るソフトウェアへのバグ混入率が定常的に増えるという影響が出そうです。工場のプラントのように日付をそもそも使わないようにしている奴は大丈夫だけど。 y2kのときに2000年がうるう年かどうかのロジックが間違っているソフトが結構発見されましたが、サマータイム処理はもっと難しいとおもう。
ところで、年月日時分秒の文字列から時刻値を得る関数って、サマータイムのときはどうなるんですかね。サマータイムが終わる日って、23:59:→00:00→00:01・・・・・→00:59→00:00→00:01というふうに時刻が推移するとおもうんだけど。0時~0:59が繰り返されて一意に定まらないんぢゃぁ??。
Re:絶対反対その2 (スコア:2, 興味深い)
01:59 (Daylight Time) → 01:00 (Standard Time)
という格好で、サマータイムの適応があるかどうかを
明記することで区別をかけている、ということのようです。
じゃあこの時間帯はユーザにサマータイムかどうか
ちゃんと入力させるかっていうとそうもいきませんが…。
Re:絶対反対その2 (スコア:1)
Re:絶対反対その2 (スコア:1)
何箇所もデータが中継するシステムだと1時間じゃなく何時間もずれそう。
Re:絶対反対その2 (スコア:1)
>工場のプラントのように日付をそもそも使わないようにしている奴は大丈夫だけど。
>y2kのときに2000年がうるう年かどうかのロジックが間違っているソフトが結構発見されましたが、サマータイム処理はもっと難しいとおもう。
そおかなあ?
どうせサマータイム処理のロジックなんてそこらに転がってるから、
それを引っ張ってきて実装するだけだよね。
国際化対応のライブラリがあるなら、 フラグ立てるだけだろうし。
あとは、一から作ろうとするバカとフラグ立て忘れるマヌケがどれだけいるかだな。
Re:絶対反対その2 (スコア:0)