サマータイム関連でマウント取りたいプログラマーがブコメやブログ書いてるけど
もしかしてこんなびっくり低レベルプログラマーが世の中のいろんなプログラミングしてるの?
サマータイムよりそっちの方が怖い。
プログラムで時刻を扱う場合はほぼほぼ100%ライブラリの機能を使う。
日付なり時刻を表すオブジェクトを作る。
そうしないと単純な引き算とか足し算が面倒だろ?
今から10日後ってどうやって計算する?一ヶ月は必ず30日じゃないんだぞ?
だからライブラリに任せる。そこそこのプログラマーなら面倒なことをいちいち実装しない。
で、そういう実装をすると内部で保存されてる時間情報と表示する情報は別物になる。
たいていは内部ではUTCで保存されていて、そいつを表示の時にJSTにする。
OSなりのロケール情報から何で表示するべきなのかを取って来てそれに合わせて表示させる。
サマータイム対応をする場合はこのロケール情報を変えるのであって、内部の時計は変更しない。
だからほとんど全ての時間的演算は影響を受けないし、コードを変える必要もない。
だから正確に言うとサマータイムが導入されても「時計は変更しない」
表示を変えるだけだ。内部時計と表示の関係をわかってない人が多すぎる。
はてなの(おそらくエアプ)プログラマーがその辺をわからずに記事にしてるのがほんとキモい。
で、そんじゃ影響はないか、っていうとそうじゃない。
さっきの10日後、みたいな演算は影響を受ける。2時間ずれる。
あと、簡単なところだとcronなんかのスケジューラは影響を受ける。
夜中の1時に実行するっていうcronの設定はロケールに応じて意味が変わるので、切り替えの時に1日に2回実行されたりするかもしれない。
ただ、利用者側に見えないところのスケジュール実行なら、ぶっちゃけサマータイム対応させる必要はないと思ってる。
サマータイムなんて所詮は人間が見たときの時間であって、内部の時計の話ではないからだ。
エクセルがタイムゾーンに対応していないとかの話もあるが、スタンドアローンで動いてるなら全く問題ない。
影響は皆無ではないしかなり大きいと思うが、OSの更新とかそんな大それた話ではないはずだ。(もちろん、将来的に変更する必要はある)
じゃぁサマータイム賛成なのか?って言われるとそれは別だ。
おそらくスケジューラの影響だけでも相当大変だし、それに関連したシステムの再検証とかどう考えても時間が間に合わない。
内部のコードがどうなってるかわからないから時間に関係してる・していないに関わらずシステムは全て再検証だろう。
どう考えても無理なのは無理だが、根本的に無理かと言われたらそうでもないはずなんだ。
もしかしてハードコードでJSTって書いてたり、独自の時間管理ライブラリを使ったりしてる人って結構いるのか?
String time = "2018-08-16 13:41:00"
とかやってんの?
スタンドアローンならそれでもいい(勝手に電源落として時計あわせりゃいい)が、そうじゃないシステムでそんなアホなことしてる人って多いの?
Fortranでかかれたようなクソ古いコードとかは大変なのでは そうでもない?
gccでいいから「表示上の日時を未来に変更した」ソースをコンパイルしてみて。 それで君の言説は論破できる。
データベース関連で日付カラムのデータをプログラムでコネコネして更新みたいなアフォコードを結構よく目にするんだが、あの辺なんでそういう発想になるんだろうな。 NOW()で現在時...
やってる本人に聞いたら時刻関連のAPI知らんだけやったわ あとUTCが何なのかすら知らないっぽい プログラマの求人って未経験者上等だからしょうがないか
JSTハードコードなんてバカげてるから自分では絶対やらないけど どこでハードコードされてるかわからんようなシステムに触る機会があるから怖いっていう人がボリュームゾーンだと思...
よく分かんないけどCobolってDatetime系のライブラリとかあるんだろうか。 あと低レベルとか書いちゃうと誤解を招くので技術力が低いとかに買えたほうがいい気がする。
低レベルプログラマーって配線弄ってそう
他人が書いたクソシステムに触らずに済むものは幸せである
タイトルからしてよっぽどな内容かと思ったら 目くそが鼻くそを笑ってるだけだったわ 99%のプログラマはお前が思ってるより低レベルだぞ お前も自分が思ってるほどではない
1年前の投稿に対して今見てるみたいに言うんだな
qiitaにもこうすべきオジサンがいっぱいるけど、若者としてはそれをやれるライブラリ作ってgithubで公開してよと思う