OpenBSD 5.5、2038年問題に対応 34
ストーリー by hylom
あと24年 部門より
あと24年 部門より
camelus 曰く、
OpenBSD 5.5がリリースされました。今回のリリースでの大きな変更点は、「2038年問題への対応」となっています（SourceForge.JP Magazine）。
# /.j には逃げ切れる方もいらっしゃると推察しますが…
2038年問題とは、1970年1月1日午前0時0分0秒（UTC）を起点としたUNIX timeが、2038年1月19日3時14分7秒で32ビットで表せる上限を超えてしまうという問題。OpenBSDではUNIX timeを扱う型（time_t）を64ビット化することでこの問題を解決している。
新曲に触れてあげないなんて・・・ (スコア:3, 興味深い)
今回のリリースソングは「Wrap in Time [openbsd.org]」ですぞ。
64bit time_t で解決でなく対応の始まり (スコア:2)
Re:64bit time_t で解決でなく対応の始まり (スコア:1)
まぁ主な問題は各種プロトコルやファイルフォーマットで 32bit な UNIX 時間が使われていることですね。
[Q][W][E][R][T][Y]
Re: (スコア:0)
ファイルのタイムスタンプを2秒単位で丸めて記録するようにすれば同じビット数で倍の期間使えるようになるぞ！
Re:64bit time_t で解決でなく対応の始まり (スコア:1)
＃ネタ元を知ってて言ってると理解していますが。
一応解説するとFAT の修正時刻のタイムスタンプは2秒単位です。
んでもって、いわゆる UNIX 時間ではありません。
[Q][W][E][R][T][Y]
Re: (スコア:0)
Windowsの標準機能でZip圧縮・展開して奇数秒が丸められても誰も気にしていないようだから、それほど荒唐無稽な話でもないんじゃね。
# NTFS拡張レコードの記録に対応した圧縮ツールを使っても、Windowsの標準機能で展開すると拡張レコードは無視されるので、やっぱり奇数秒は丸められる。
一方 Borland C++ 5.5.1 は (スコア:0)
time_t の実態が 32bit の符号付き整数であるにも関わらず
内部では符号なし実数として扱っているのでした。
((~ (time_t) 0) (time_t) 0) = 1
0x80000000 = 2038-01-19 03:14:08 UTC
0xFFFFFFFFF = 2106-02-06 06:28:15 UTC
Re: (スコア:0)
バイナリファイルでバイナリ形式で、日付保存していたらバイナリファイルのフォーマットから見直しが必要で悲惨
下手にコンパイルし直すと読み込むバイナリがずれて、プログラムが暴走しかねない
Re: (スコア:0)
time_t が long なシステムが多いようですが、
これをunsigned longに直すだけで、あと70年近く先送りできると思うのですが…>32ビットunix
たとえファイルにバイナリで埋め込まれていてもそのまま対応できるし。
まあ一部ソースでtime_tが符号付きだと思い込んで大小比較してるようなやつは修正の必要がありますが、C言語規格でもtime_tをunsignedにしてはいけないみたいなことは書いてないので、それはそもそもそのソースが規格外ということで。
Re: (スコア:0)
Re: (スコア:0)
その問題は弥勒菩薩様がなんとかしてくださるはず。
Re: (スコア:0)
>time_t = 64bit
「コンパイル エラー:
修正候補: ステートメントの最後」
by VBA
-- う～ん、バッドノウハウ？
Re: (スコア:0)
おもしろいつもりなのか？
24年後 (スコア:1)
現役世代はあらかた生きているんではなかろうか。
# うちのとーちゃんも50歳くらいから、5年以内に死ぬからと言い続けて78歳になりました
Re:24年後 (スコア:2)
逃げ切れると思っていたら定年延長されるとか…いまのご時世ならありそう
＃そのころには機械がコーディングするので無問題です。タチ○マとかならコード書くくらい余裕そうだし。
Re: (スコア:0)
2000年問題のとき引退したはずのCOBOLプログラマーを呼び戻して対応したという前例がすでにあるし。
# COBOL自体には2000年問題がないのに(なにしろ数値は基本BCD)対応しなければならなかったんだからtime_tの64ビット化だけで済むわけがないことなんて超明らか
Re:24年後 (スコア:1)
Re:24年後 (スコア:3)
管理職として責任だけ取らされる可能性も…。
Re:24年後 (スコア:2)
このコードを書いたのは誰だ！って叫んだ新人に、
父親より年上の上司が反応する負の連鎖がまたしても
Re:24年後 (スコア:1)
その人のダイイング・メッセージはおそらく:
いろはにほへと
ちりぬるをわか
よたれそつねな
らむうゐのをく
やまけふこえて
あさきゆめみし
ゑひもせす
だろうなあ。
折句(沓)。
なぜ死んだ？ (スコア:0)
解かなくて死す？
とか無くて死す？
Re:なぜ死んだ？ (スコア:1)
広く知られている解は「咎無くて死す」ですが革新的な解釈を持ち込むのでしたらそれはご自由に。
Re: (スコア:0)
戦中戦後の食糧難を少年少女で過ごした我が両親も健在。
Re: (スコア:0)
喰ったんか！？
ならば (スコア:0)
現在の幼稚園児・保育園児世代から「2038年は大変だ！大変だ！！」と刷り込み続ければ
20年後には立派な意識高い人になってくれると思います！！
Re: (スコア:0)
私は「1999年に世界は滅亡する」と聞かされて育ってきました。
結果、意識高くなってるかどうかはわかりません。
それでも (スコア:0)
問題の先送りでしかない。
Re: (スコア:0)
西暦の方を0に戻すべきだよね。
#問題の逆戻りでしかない。
Re: (スコア:0)
西暦の方を0に戻すべきだよね。
それは、2038年問題を先送りするよりコストがかかりそう。
Re:それでも (スコア:1)
2000年問題華やかりし頃、外国人のエンジニアに「日本には元号があるから日付の扱いは気をつけてやってるだろ？」と聞かれて返答に困ったことを思い出しました。
Re: (スコア:0)
新暦after epochに移行しましょう
Re: (スコア:0)
メシア(キリスト)が生まれ直すんですよ。
Re: (スコア:0)
15年も前に既出のネタで今さらドヤ顔されても
https://tools.ietf.org/html/rfc2550 [ietf.org]
printfが (スコア:0)
昔、printf("Log @%d : Value = %d\n", time(NULL), foo )みたいなコードを書いて、
Valueがずっと０で「??」と難儀した記憶があるなー。
#VC2005だったから、GCCみたいにprintfフォーマット警告が出なかった