アカウント名:
パスワード:
ソフトウェアサービスだと、タイムゾーンへの対応は当然行いますよ。内部では UTC で管理して、見せる方は Localtime にするってことですよね。表示の変更はユーザが選ぶようにしてるので、自動にはあえてしなくてもいいかなと。きりがないので。
内部がUTCならいいんだけどとくに日本国内向けのサービスだとたいていJSTになっていて阿鼻叫喚
これはUTCならいいとかそういう問題じゃないんだ。時差をoffset=new Date('Z')；epochLocaltime=UtcLocaltime+offset;
みたいにしてとっているとき、それが違う標準時で適用されていないか、つまり最初に取った値をずっと使うような処理になっていないか調べないといけない。そして、today=new Date();yesterday=today.clone();yesterday.day=today.day-1;dateString=yesterday.toStr();
みたいになっているとき、処理系の中で使われる標準時はnew（）したときのものかtoStr()したときのものか調べないといけない。結局、全部のプログラムを見直さないといけないというのと同じくらいボリュームあるんだ。
2000年問題の再来くらいの処理なんだけど、システムの数が2000年から増えている。とてもただでなんかできないよ。
＃例はどの言語でも大体ありそうな記述にしただけで厳密にどれにならったというのはない、関数の名前とかは適当に解釈してください。
内部的にはすべてUNIX時間とかUTCで表現されていて、表示時のみローカルタイムに変換するようにしておけばいいんじゃないの？そもそも時刻を文字列で扱うべきじゃないし。
その、ローカルタイムに変換する基準が2つあるというのがちゃんと理解されていないプログラムばかりなので全部検討し直しから始めないといけないということ。＃今は一つしかないのでぞんざいに扱っても露見しないだけ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
控えめな対応 (スコア:0)
ソフトウェアサービスだと、タイムゾーンへの対応は当然行いますよ。
内部では UTC で管理して、見せる方は Localtime にするってことですよね。
表示の変更はユーザが選ぶようにしてるので、自動にはあえてしなくてもいいかなと。
きりがないので。
Re: (スコア:0)
内部がUTCならいいんだけどとくに日本国内向けのサービスだとたいていJSTになっていて阿鼻叫喚
Re:控えめな対応 (スコア:0)
これはUTCならいいとかそういう問題じゃないんだ。
時差を
offset=new Date('Z')；
epochLocaltime=UtcLocaltime+offset;
みたいにしてとっているとき、それが違う標準時で適用されていないか、つまり最初に取った値をずっと使うような処理になっていないか調べないといけない。
そして、
today=new Date();
yesterday=today.clone();
yesterday.day=today.day-1;
dateString=yesterday.toStr();
みたいになっているとき、処理系の中で使われる標準時はnew（）したときのものかtoStr()したときのものか調べないといけない。
結局、全部のプログラムを見直さないといけないというのと同じくらいボリュームあるんだ。
2000年問題の再来くらいの処理なんだけど、システムの数が2000年から増えている。
とてもただでなんかできないよ。
＃例はどの言語でも大体ありそうな記述にしただけで厳密にどれにならったというのはない、関数の名前とかは適当に解釈してください。
Re:控えめな対応 (スコア:1)
内部的にはすべてUNIX時間とかUTCで表現されていて、表示時のみローカルタイムに変換するようにしておけばいいんじゃないの？
そもそも時刻を文字列で扱うべきじゃないし。
Re: (スコア:0)
その、ローカルタイムに変換する基準が2つあるというのがちゃんと理解されていないプログラムばかりなので
全部検討し直しから始めないといけないということ。
＃今は一つしかないのでぞんざいに扱っても露見しないだけ。