アカウント名:
パスワード:
ソフトウェアサービスだと、タイムゾーンへの対応は当然行いますよ。内部では 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()したときのものか調べないといけない。結局、全部のプログラムを見
内部的にはすべてUNIX時間とかUTCで表現されていて、表示時のみローカルタイムに変換するようにしておけばいいんじゃないの?そもそも時刻を文字列で扱うべきじゃないし。
その、ローカルタイムに変換する基準が2つあるというのがちゃんと理解されていないプログラムばかりなので全部検討し直しから始めないといけないということ。#今は一つしかないのでぞんざいに扱っても露見しないだけ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
控えめな対応 (スコア: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()したときのものか調べないといけない。
結局、全部のプログラムを見
Re: (スコア:1)
内部的にはすべてUNIX時間とかUTCで表現されていて、表示時のみローカルタイムに変換するようにしておけばいいんじゃないの?
そもそも時刻を文字列で扱うべきじゃないし。
Re:控えめな対応 (スコア:0)
その、ローカルタイムに変換する基準が2つあるというのがちゃんと理解されていないプログラムばかりなので
全部検討し直しから始めないといけないということ。
#今は一つしかないのでぞんざいに扱っても露見しないだけ。