[特設]サマータイム対応相談室
■ このスレッドは過去ログ倉庫に格納されています
まともに設計されたシステムならシステムでは一切問題おきない
まともな教育を受けてない低学歴知恵遅れのぼくが設計したシステムだと
アタリマエのように問題が多発する
知恵遅れのなんちゃってシステム屋か
パチョコンの大先生がテキトーなこといってるだけだからな
全世界では、普通にシステムで夏時間が運用されてるワケだからな
https://www.time-j.net/
https://www.time-j.net/WorldTime/Area/NorthAmerica
かりにこんな知恵遅れなヤツラがコードいじってるかと思うと
ホントなぞっとするわ 知恵おくれ↓
2 名前:デフォルトの名無しさん[] 投稿日:2018/08/14(火) 21:34:18.46 ID:FLQzRhNo [1/2]
オレのvistaですら
すでに日本の夏時間対応済になってんのに
なにいってんのコイツ
3 名前:デフォルトの名無しさん[] 投稿日:2018/08/14(火) 21:40:58.04 ID:FLQzRhNo [2/2]
(GMT+11) サハリン
(GMT+11) ソロモン諸島、ニューカレドニア
(GMT+11) チョクルダフ
(GMT+11) ノ-フォーク島
(GMT+11) ブーゲンビル島
(GMT+11) マガダン
この中から好きなの選べばいい
コレで日本のサマータイム対応だからな
システムに一切問題なんかおきない
正しく動作する サマータイムを想定した設計になってればサマータイムになっても問題ない、なんていう小学生でもわかることを延々繰り返して100レスくらいしてるよなこいつw ×サマータイム想定したシステム
○普通に国際化対応されたシステム
あのなシステムというのはクソニートが
ママに動いてるとこみせるもんじゃないわけ オマエもママもずっと日本にしかいないからな
アメリカにいってアメリカのタイムゾーン設定して
計算機の動作がおかしいおかしいとひたすらいってるのが
このスレのクソニート知恵遅れだからな >>266
ところで先生はどういう仕事してるの?開発職? キャー今日も先生がいらしてますよー!
みんなもてなしてあげて♡ このスレでクソニートを更生させる仕事してる
クソニートがどんだけクズでゴミな存在なのか自覚させる仕事してる >>269
それは崇高な仕事だね。
でもお金にならないでしょう。 >>253
ローカル時刻を入力するUIてのは、ありそうで無さそうなんだよな。
× 先物で、時刻指定で下限なしで約定
× 15時に自動決済
× 時刻指定で配送
× 時刻表の表示変更(相対時刻表示で運用できる。出力を夏時間に合わせたところで、結果は同じ)
対応するなら、夏時間の対応せずに
「この時刻は夏時間ではありません」
と表示して夏時間ガン無視が最も合理的でリスクがない。 >>259 >>260
半角先生も、GMT+11な他の土地のタイムゾーンを流用しては
解決にならないことを悟られたようで何よりです
getTimezoneOffsetも、Dateオブジェクトの値によって
その時点のオフセットを調べてくれますもんね >>271
うちのサービスだと有りそうで実際にあるわ。
作業記録の開始日時と終了日時を入力する画面がある。
どうすっぺかなー また知恵遅れ意味不明なこといってるわ
普通でもgetTimezoneOffsetすら使わないからな
もともとすべて時刻はUTCで保存だからな
あとIANAのソースとデータののリンクはってやってるのに
それすら読まない
いや読むことができる程度の知能がない
知能に相当な問題がある
知能に軽度の障害があると推認できる いやだなー
これまでUTCとOSの機能を使えと主張しておられた半角先生が
まさか今更データーベースを抱えて自前で処理しろなんてことをおっしゃられるとは 知恵遅れがボクの考えた設計とかどうでもいいわけ
いかんせんオマエは知能に重篤な障害がある
それを自覚したほうがいい >>264
サマータイムが二時間のシステムなんかどこにもないって話はずっと無視されてんだよなー。
なんか森とか遠藤の手下なんじゃないの?自民党の工作員は時々質が著しく低いんだよ。 なるほど
暴れてるのはパヨチョンか
だったら知恵遅れなのはしょうがない
知恵遅れでないとネトウヨやパヨチョンにはなれない おーまた来てる
おんもしれえなこのキチゲェが!
ぜひなんJに来てレスバしてほしい >>269
自分から更生しろよ
間違い指摘されているのに毎日同じようなこと連投するキチガイとか何のために生きてんの 間違い?
ホンキでそんなことをいってるのが恐ろしいわ。。。
アマゾンがクライアント計算機のローカル時刻を保存してるとホンキで思ってるワケか
クライアント計算機からローカル時刻の入力がある場合でもな
クライアント計算機が設定してるタイムゾーンがなんだろうが
アマゾンのサーバーは知ったこちゃないワケ
アマゾンはクライアント計算機で設定されてるタイムゾーンに従って
処理するだけだからな まず、低学歴知恵遅れは時刻というもんが
なんにも理解できてない
まともな教育を受けてないとこうなる 変換の根拠は、クライアント計算機に設定されてるタイムゾーン
日本に住んでるくせにアメリカのタイムゾーンに設定したら、
当然アメリカの時差の基準で処理される
それ以外なにもない まともなシステムなら
ローカル時刻の入力があっても
クライアント側でUTCの時刻に変換してからサーバー側に送るからな それつまりクライアント側がAsia/Tokyoのサマータイムに対応してなくてオフセット9時間で計算しちゃったら詰むじゃん クライアント側のローカル時刻がUTC+09:00なら
時計でもUTC+09:00で表示されてる
なにも間違ってない
設定どおりに表示されてる
頭悪いの? Asia/Tokyoの文字列でサマータイムに対応してないボロイ計算機は
>>262 ←この設定でいける
なんの支障もない
問題なんか起きようがない
回避手段まである 相変わらず話の前提を無視した上に自分では勝手に非現実的な前提をつけててワロタ で、アホはいまだに概ねの計算機で時刻をどう扱ってるか分かってないようだからな
なにがどうなってるか分かるようにjavascriptでアホ教育用のサンプルコードを書いてやったわ
https://ideone.com/Yl3GjP
一部抜粋する
コレで分からないなら人間やめたほうがいい
ホモサピエンスに分類できる知能がない
var ahoDate = new Date();
var ahoTime = parseInt(ahoDate.getTime() / 1000); // 保存する時刻(普通は秒単位で十分)
var ahoTimezoneOffset = ahoDate.getTimezoneOffset(); // ローカル時刻の入力がある場合以外、普通は使わない
var ahoTimezone = -ahoTimezoneOffset * 60; // ローカル時刻の入力がある場合、この秒数分だけ引く(JSTなら9*60*60の値になってる)
print("POSIX Time : " + ahoTime + " sec");
print("TimezoneOffset : " + ahoTimezoneOffset + " min");
print("Timezone : " + ahoTimezone + " sec");
// ↓アホ教育用 コレでアホでもなにがどうなってるか分かるハズ
var ahoTimeAho = ahoTime + ahoTimezone;
var ahoDateUTC = new Date(ahoTime);
var ahoDateJST = new Date(ahoTimeAho);
ahoDateUTC.setTime(ahoTime * 1000);
ahoDateJST.setTime(ahoTimeAho * 1000);
print(ahoDateUTC.toUTCString());
print(ahoDateJST.toUTCString()); クライアントの現在時刻じゃなくてUIから手動で任意の日時を入力して送る時の話だってんだよアホ アホはDateコンストラクタの引数入力値に
任意の値が設定できることもしらないワケか
まずリファレンスを読む能力がない var ahoDate = new Date(2018, 8, 15, 22, 27, 00);
こんな感じでフォームオブジェクトから値とって設定するだけだからな
サルでも分かりそうなことが理解できない
やばいわ。。。 それがなんの解決にもなってないことがわからない辺りがさすがマジキチ var ahoDate = new Date(2018, 8, 15, 22, 27, 00);
var ahoTime = parseInt(ahoDate.getTime() / 1000); // 保存する時刻(普通は秒単位で十分)
はっきりいってな2行で済む
ahoTimeをサーバーに送るだけでおしまい >>297
もしそれで本当に解決できてると思ってるなら頼むからお前が書いたコードを世に出すのはやめてくれよ オマエみたいな知恵遅れが知恵遅れな作りにしたんだからしょうがない
知恵遅れが開き直ってるしな ホントな知恵遅れは知恵遅れ設計の問題点がわかってない
だからいつまでたっても人間になれないわけ POSIXタイム用のインターフェースなんか
いまどきどんなシステムでももってるからな そもそもサマータイムで問題は起きないから対応なんて必要ないって主張だったはずなのにコードの修正例を載せようとしちゃってる矛盾に気がついてないあたりとても好きだよ。 まともなシステムなら問題がおきるわけがないからな
当然の設計ができてないワケだからな
まともな人間が設計すればおきないことがおきると
自信満々にいってるワケだからな
知恵遅れが知恵遅れな設計で知恵遅れシステム作ってますといってる以上
こうしか書きようがない
まともな人間ならありえないことを平気でやるわけだからな 知恵遅れが自分が知恵遅れであると
自白してるのがこのスレだからな
その自覚がない
ゴミでクズのくせにそういった自覚がないのは
クソニートや低学歴底辺に多い
コレは定説 タイムゾーン大先生はスルーして
>>271
うちの納品したシステムでも普通にあるわ。
メディアプレイヤーの大げさなもので、ユーザー(博物館とかの運営者)が時刻を指定して
特定のコンテンツを特定の時間に再生するようなもの。
サイネージ系だと結構普通にあるんじゃないかな。
もっとも、JDTのローカルタイムに読み替えで問題があるケースは、太陽の位置に依存したコンテンツとかに限られるだろうけど。 >>259
> アホが知恵遅れな作りにしてるからそうなるワケ
知恵遅れじゃないよ。必要になってないのに
サマータイム導入でしかも2時間に対応するなんことはしないの
むしろしたらダメなんだよ。2時間は世界のどこでも使われてないんだから
それを言ったら3時間はどうする? 年に複数回あったらどうする?とかまでなっちゃう
この話が勃発する前に客が求めてもないのに、日本がサマータイム導入されたときの
仕様はどうしましょうか?なんて、質問したらダメなの。無駄なコスト。
質問したところで考慮しなくていいって言われるだろうし 確かに、自分から日本滅亡のスイッチを押す必要は無いな。 ホントな低学歴知恵遅れは頭悪すぎて
涙がでてるくるわ。。。
こんだけ懇切丁寧に説明してやってるのに
いまだになにも理解できてないからな
むしろローカル時刻で保存するほうが
余計な対応をしてる
普通にひたすらUTCで交換すれば
システムでは問題なんかおきようがない
しかもそっちのほうが自然な作りになるしシンプルで簡単になるからな
普通につくればタイムゾーン変更すればそのとおりに動く
2時間だろうが3時間だろうが関係ない
かりにパリのタイムゾーン設定したり、ニューヨークのタイムゾーン設定しても
普通にそのタイムゾーンとおりに動くのと同じだからな
低学歴知恵遅れがいちいち余計なことしてコレもできなくしてるだけだからな
そもそもサマータイム対応以前の問題
低学歴知恵遅れはやらなくていい余計なことをして
いちいち問題おこしてるワケ
わかる? まず低学歴知恵遅れは
システムのTZやLOCALEやNLSみたいな環境変数がなんのためにあるかすらも
なんにも理解してないのがよくわかったわ
低学歴知恵遅れが作る程度のシステムでは
特殊な要件がないかぎり、余計な独自の実装とかもともと不要だからな
使用してるシステムのもともとある基本機能にまかせるのが一番簡単なのはアタリマエ
それやらないでいちいち余計なことして問題おこしてるワケ
※ すべてまともな教育を受けてない白痴に由来する
低学歴知恵遅れにシステム設計させると
日本のタイムゾーンがかわると太陽の軌道計算までずれるような作りに間違いなくすることが
↓このレスから予見できる
>>305
日本のタイムゾーンがかわっても 太 陽 の 移 動 が か わ る ワ ケ が な い からな
※ ちなみにユリウス日はPOSIXタイムと考え方的には同じ
つまり、低学歴知恵遅れがシステムを設計すると普通にこんなことがおきる
それが普通だと自信満々でいってるワケだからな
おそろしい。。。 >>310
えとさぁ、だからみんな言ってるじゃん?
サマータイムのことなんか考慮してないで
作ってるから大問題になるって。
サマータイムのことなんか考慮してないっていうのは
そのTZやLOCALEやNLSみたいな環境変数のことなんか
全然見てないってことだよ?
だから大問題になるって言ってるのに > サマータイムは全体をずらすものなのだから
> サマータイムの始まる前の時間もずれるべきだろ?
> 違うの?
違う。決められた時間(世界的には夜2時が多いらしい)に
1時間時計を進める。言い換えるとその日が23時間になる。
また終わるときは1日が25時間になる。
夜間が短くなるということは、夜間バッチを開始して
処理完了までの猶予時間が1時間減るということ。
もちろん2時間ずらすなら、2時間ずれる
夜中の2時に初めて朝6時までに完了、すなわち4時間の間に
終わらせればよかった処理が、半分のたった2時間になるということ サマータイムで問題になるのは "今日" のデータを集計する時
当たり前だが日本で今日といったら、JSTの時間で
今日にあたるデータを集計しなければいけない
ではサマータイムに突入する日、この日は23時間しかない
では23時間分のデータを集めるので良いのか?
といったら要件による
今日一日のネットワークトラフィックであれば24時間の方が適切だろう。
だけど今日一日の来場者数であれば、23時間分で良いだろう
すなわち何が適切かを全て見直さなければいけない
それが一番大変 サマータイムがあったからって、UTCで扱えば
問題ないかのように言ってるやつがいるがそれは大間違いだ
なぜなら、UTCは変わらずとも人間の行動が変わるからだ
日本時間朝10時(=UTC 1時)に業務開始だったものが
UTC 0時に業務開始に変わる。
その他すべての日本人の行動が、UTCで見て1時間早くなる オレのエレガントなサンプルコードをみればわかるとおり
クライアント側ではタイムゾーンなんか一切気にせずに
タイムゾーンを含めて時刻を処理できることがわかる
しかも超簡単
↓エレガントなサンプルコード
https://ideone.com/pOGvRt
ほとんどエクセルでマクロ作ってコピって作ったわ
こんなもん人間が作るもんじゃない。。。
@日本時間 https://i.imgur.com/m4EO0sL.png
Aニューヨーク時間(現在サマータイム中) https://i.imgur.com/k6IFr2b.png
Bパリ時間(現在サマータイム中) https://i.imgur.com/2vOsBYd.png
C日本時間(サマータイム) https://i.imgur.com/iNfxjHn.png
サーバーからPOSIXタイムを取得できたら
超簡単なsetSelectLocalTime()を呼びだすだけで
プルダウンの時刻が復元できることがコードから分かる
クライアントは超簡単なgetSelectLocalTime()を呼びだして取得できた値(POSIXタイム)を
サーバーに送信するだけで適切な時刻が送信できることがコードから分かる
サーバー側でもクライアント側の時差なんか一切気にする必要ない
特殊な要件でもないかぎり、そもそもサーバー側で時刻を保存するためにタイムゾーンの情報すら取得不要
クライアント側は、クライアント側で設定されてるタイムゾーンにあわせて表示する(超簡単なsetSelectLocalTime()を呼ぶだけ)だけだからな
※ つまりまともに設計されてるなら作るとき時差すら意識する必要すらない
※ コードの修正すら不要 システムの設定を更新する作業だけの話だからな そして簡単な試験しておしまい
※ こんなに簡単にできるのは、もともとシステムが国際化の基本機能を実現してるからだからな
※ そして、それはクライアント側でもサーバ側でも実現されてる もしかして低学歴知恵遅れは
アマゾンがいちいち夏時間を設定してないクライアント計算機の時差まで
考慮してくれるとか思ってんの?
もしかして低学歴知恵遅れは
クライアント計算機に夏時間の対応がなかったら、
クライアント計算機からアマゾンで買い物できなくなるとか思ってんの?
もしかして低学歴知恵遅れは
日本が夏時間になったら
日本からアマゾンで買い物できなくなるとか思ってんの?
もしかして低学歴知恵遅れは
日本が夏時間になったら
アマゾンが大混乱するとか思ってんの?
マジでそんな頭悪いこと思ってんの? データをUTCで記録していたとしよう。
そうすると人間の行動が1時間早くなることで
例えば何かしらのデータのピーク時間が
UTC 5時からUTC 4時にかわってしまうことになる。
日本的には特に何も変わってないわけだが、
データ上は大きな変化が発生したことになってしまう。
だからデータの種類によっては、サマータイムを考慮しなければならない
データをUTCで記録していたって、システムの仕様変更が発生する例だ 時系列の時間発展のデータでなにをアホなこといってんのコイツ
著しく知能が低いヤツがいうことはホントな意味不明なことをいう
システムの問題じゃないからな >>316
> 日本が夏時間になったら
> アマゾンが大混乱するとか思ってんの?
大混乱は発生しないかもしれないが、多少の混乱は発生するだろうな。
なぜなら商品の売れる時間帯が1時間ずれることになる
時間帯によって売れやすい商品を検索の上位にしていたりすると
売上にも影響は出てくるだろう >>320
計算システムは問題なくても
大混乱が起きるって話をしている。 あのなサマータイムのこと考慮してないで作ってないレベルじゃないワケ
常識的な設計ができてないという話だからな
いちいち日本だけで動けばイイように作る必要がそもそもないからな
手間なんかかわらないのに >>322
> サマータイムは全体をずらすものなのだから
> サマータイムの始まる前の時間もずれるべきだろ?
> 違うの?
違う。決められた時間(世界的には夜2時が多いらしい)に
1時間時計を進める。言い換えるとその日が23時間になる。
また終わるときは1日が25時間になる。
夜間が短くなるということは、夜間バッチを開始して
処理完了までの猶予時間が1時間減るということ。
もちろん2時間ずらすなら、2時間ずれる
夜中の2時に初めて朝6時までに完了、すなわち4時間の間に
終わらせればよかった処理が、半分のたった2時間になるということ やっぱりな低学歴知恵遅れは
問題の本質がなんにも理解できてない >>322
サマータイムで問題になるのは "今日" のデータを集計する時
当たり前だが日本で今日といったら、JSTの時間で
今日にあたるデータを集計しなければいけない
ではサマータイムに突入する日、この日は23時間しかない
では23時間分のデータを集めるので良いのか?
といったら要件による
今日一日のネットワークトラフィックであれば24時間の方が適切だろう。
だけど今日一日の来場者数であれば、23時間分で良いだろう
すなわち何が適切かを全て見直さなければいけない
それが一番大変 >>324
問題の本質は、サマータイム導入で
システム改修のために長い検証期間と
大きなコストかかるってこと。
お前は計算システム "だけ" 動いてるから
それで満足していればいいじゃないですかw そんなもん決めの問題だからな
一回決めたらおしまい
低学歴知恵遅れはどうでもいいしょうもない心配しかしないからな
しかもこのスレにいるような低学歴知恵遅れには無関係な話 要件通りに適切に動いてるのに
かえろというならおカネもらうだけだからな >>327
ほら、言い返せなくなっちゃったw
夜間バッチの時間が1時間短くなっても
計算システムは動いてますからねーw
ただ朝の営業時間に間に合わなくなるだけですよねーw 低学歴知恵遅れのは
開発したほうに間違いなく瑕疵がある >>328
だから一日が23時間になることで、また世界的に見ると
日本人の行動がUTC時間で1時間早くなることで、
もともとの要件を満たせなくなってないかの検証に
莫大な時間とコストがかかるっていうのが本質的な問題 また同じこと繰り返すのか
>>90>>92>>112>>125>>126
>>127>>128>>130
>>131
もう散々きっちり回答済だからな
もう相手はしない 半角の人、繰返してるって自覚はあるんだ
ずっと同じこと言ってるよね オレはピンポントで回答はできるだけユニークにしてる
SQLでdsitinctつけたような美しい回答だからな
情報価値も高い このスレは現実にサマータイムに対応が必要なシステムを扱う人間のためのものなので
対応が必要ないと思う人は専用のスレでも立ててそっちで啓蒙してくれないかな 要件に合わせたDateTimePickerみたいなのを自作しちゃってるところは大変だよな
特に終了日の重複時刻を入力された時にそれがUTC換算でどちらを意図した入力なのか判断しようがない
ネットオークションの終了日時の設定とかどうすんだろ 自由に時刻が入力出来るところはもうそれがUTC+9なのかUTC+11なのかをユーザーに明示してもらうか、どちらか決めうちであることを明記して換算してもらうかしかやりようがない気がするな。
結局システム屋だけじゃなくて一般ユーザーも何かしらの対応が必要になる。やっぱ影響でかすぎる。 頭が弱い人は、サマータイムが起きてもUTCで扱っていれば
コンピュータは止まらないから問題ないとか言ってるが
論点はそこじゃないんだよね。
論点はサマータイムが起きた時、それをどのように扱いたいのかという仕様の話
一日が23時間 または 25時間の日ができるが、その時間で処理して良いのか
24時間に数値を補正するのか、UTCでみた24時間として
(つまりサマータイムがなかったものとして)処理するのか
世界的に見ると日本人が1時間早く行動するようになるが、
それに世界は合わせてくれるのか。
コンピュータさえ動いていればOKとか言ってるから
現実には大きな問題が発生することに気づけない アホ「サマータイム導入するかもしれないので、今から対策を考えましょう
2時間になるかもしれません。それを考慮しようと思います。
でもいきなり2時間ずれるとか体内時計がついていかないと思うんですよ。
きっと政府は、1時間ずつ二回に分けてずらすとか言うと思うんですよね。
だからスプリングタイム、サマータイム、そして秋にサマータイムの終わり、
冬にスプリングタイムの終わりってやると思うんですよね?
今からそれに備えて対応したいんで金ください
YAGNIなんて敵ですよ。予めいろんな事態に備えないと。金ください」 >>333
いや、タイムゾーンとサマータイムが区別ができていなかったのが、
一応ぐぐって調べた痕跡はある。 サマータイム開始日と終了日が明確なら対応は簡単じゃないの?
始業時間をちょっと変えてバンって感じで
勤怠プログラム作ったこと無いから平気で言えるけど >>342
まんまブラック顧客が言いそうな暴論でワロタ >>342
まず大抵の国内向け勤怠管理はJST決めうちで作ってあるはずだから、ここを何かしらの方法で直さなくちゃいけない。
でもってそれを直すことで副作用がないかどうかテストをしなくちゃいけない。
これでシステムの内部的には勤務時間を正確に計算できるようになったとして、
次にこれを画面に表示したり印刷したりする場合にどう表現するか考えて、それを実装しなくちゃいけない。
サマータイム期間内と期間外をまたぐ勤務時間があった時に、ただ09/15 03:00とだけ書いてあったらそれが1度目の3時なのか2度目の3時なのかわからない、など対処すべきことは沢山ある。 >>342
プログラムを直すのなんて簡単なんだよ
問題は、例えば夜勤の人がタイムゾーンをまたぐとき
その日は勤務時間が短くていいのか、短いとしたら給料も減らしていいのか等を決めないといけないだろ?
そういうことを考えてない上から改修しろと言われてしまうと
意見伺いや仲裁も全部SEの責任になって大変面倒なことになる
当然勝手に決めたら怒られる まだ低学歴知恵遅れそんなこといってんのか
システムではサマータイムもタイムゾーンも扱い方も管理のしかた同じなのに 低学歴底辺の負けず嫌いは異常だからな
ホントなすぐに分かる なんどもいうようだが
まずな低学歴底辺の知恵遅れは
自分がいかにゴミでクズな存在なのか自覚する必要がある
ホントなゴミクズのチンカスだからな
わかってんの? >>346
システムの動作に依存するパラメータが法令にある時刻で(労基法の深夜割増は22時からとか)、
そのパラメータがサマータイム例外規定とかで一部の工場は24時からとかになったらどうするのって話なわけで
UTCで管理してれば2時間のズレは表示上の問題でしかない、という話以上の問題がそこにはあるだろう
法令の時刻をDST実施中にUTC+9で読めばいいのかUTC+11で読めばいいのか現時点ではわからないのだから
例えば深夜割増の開始判定時刻は現状では365日JSTの場合しかないからUTCの13時と決まっているけれど、
今後の行政の動き次第では開始判定時刻がUTCの11時になったり、UTCの13時になったりとケースバイケースなわけで、
そんなの事前にシステム設計側で把握しておくことは不可能だっただろうって話だ。
そもそもJSTのローカルタイムのままシステムを動かすのか、JSTで表現されたローカルタイムをJDTとして再解釈して
システムを動かすのかもケースバイケースなわけで、スタンドアロンなシステムなら単なる決めの問題だが、
連携して動いているシステムでこの方針を統一できない場合もあってその場合はテストを相当にやりなおさなくちゃいけないだろう
ただそれを説明してお客さんが納得してくれるとも限らないからタイムゾーンを変えるなんてことを本当にやるのか?と皆思ってるわけで 簡単にまとめると、サマータイムが一時間だとして
1. サマータイム開始時・・・一日が23時間になる
2. サマータイム終了時・・・一日が25時間になる
3. サマータイム中・・・世界基準で考えると日本が一時間早く動き出す
4. サマータイム導入前に記録されたデータは上記に当てはまらない
5. サマータイム導入後に撤回されたら未来の予定に調整が必要
ってところかな。5は撤回されなければ対応する必要はないけど
なんか導入してダメだったらやめればいいだけって考えてそうだから、
やめるのにもコストが掛かりますよってことで書いた 通信手段を持たない組込機器とか、誰がアップデートするの? >>351
そう。試験導入とか、2年で一旦やめるとか、アホの極み。 半角くんってエンジニアじゃないよな。
仮にシステムに関わる人間だとしても、渡された詳細設計書通りにコードを書くことしか出来なさそう。
見えてる視野がそのレベルの広さしかないんだもん。 web屋とかなら半角くんも間違っちゃいないけどな
工場のシステムとか他社システムが絡むもんの入れ替えとか考えたくもないわ >>356
Web屋から見ても何から何まで間違っとるわw
静的なhtmlのサイトでちょっとjQueryでアニメーションつけてるくらいなら間違ってないだろうけどw >>350
やるなら法定時刻はUTCで定めてくれると、逆にありがたいけどね。
ただ海外、大陸をみると、現地時刻は幾つもある。
西海岸時間、中央時間、東海岸時間、あとはあるかはしらんが、ハワイのローカルタイム。
イギリスでもあんま知られていないようだが、太平洋に領地を持っていたりした。
数十年前なら香港なんかがある。
さて、そういう幾つものローカルタイムを文化として持った国は、法定時刻をどのように扱っているのか?
法的文書は、UTCで記録するのが、合理と思うが、タイムスタンプには、必ず「その時点の時差」を記録させる運用でないかと思う。
で、夏時間対応は、この時差記録機能の追加が柱になるんでないかと、個人的には考えている。
まあ、決めるのはじみんとー >>344
時差、タイムゾーンは、相対的な時刻の表示を替えること。
生活習慣上の時間軸で定められた時刻であれば、内規、おれルールを替える必要はない。
明日から9時が2時間早まるといって、わざわざルールを夏時間無適用の時刻で定め直す余計な手間になるから、そういう影響は少ないかと。 何にしろ誰得?みたいな話。
政治ねたを引用すれば、ある新聞社は、夏時間導入に大賛成したけど、明るい内に呑みに行けないからと記者が厭がって廃止に世論を誘導して廃止させたとか、
そーすは不祥事のあと落ち着いたのに、やめもしないアイツ ■ このスレッドは過去ログ倉庫に格納されています