GNU C Library、Y2038対策でレガシーABIに64ビット時刻のサポートが追加

headless 曰く、

GNU C Library(Glibc)の2038年問題(Y2038)対策パッチで、レガシーABIに64ビット時刻のサポートが追加された(Phoronixの記事、 コミット情報)。

Y2038はUNIX時間が2038年1月19日3時14分7秒(UTC)以降、符号付32ビット整数で表現できる範囲を超えるという問題だ。レガシーABIでは32ビットのtime_tがデフォルトになっているが、新しいビルドフラグ「_TIME_BITS」を指定することで、64ビット時刻シンボルの使用が有効になる。ただし、有効化するにはLFS(_FILE_OFFSET_BITS=64)の指定も必要とのこと。

2038年に32bitが残っているとも思えないし

[Anonymous Coward]

いまからやっておけば安心

time_tをすぐに64bitデフォルトにしてもトラブらずに移行できる気もするけど(甘いか)

Re:2038年に32bitが残っているとも思えないし

[Anonymous Coward]

過去に作成されたファイルで日付がバイナリ形式で保存されているとコンパイルし直すだけじゃ済まないから対応が面倒臭いかも。

Re:

[Anonymous Coward]

既存データは困りますよね。個人的には特に↓がやべぇと思ってます……。

https://dev.mysql.com/doc/refman/8.0/en/datetime.html [mysql.com]
> The TIMESTAMP data type is used for values that contain both date and time parts.
> TIMESTAMP has a range of '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC.

Re:

[Anonymous Coward]

DB関係は、直さないとこは意地でも直しませんからねぇ…

Re:

[Anonymous Coward]

4ビット消費してマイナスと1秒、5秒～1年刻みのtime値にしよう。
紀元前どころか人類史前も年単位で表せるtimeを提供

Re:

[Anonymous Coward]

電卓やキッチンタイマー、時計(スマートウォッチ除く)とかに64bitCPUが乗るとは思えない

Re:

[Anonymous Coward]

その手の機器にglibcが乗るとは思えない

Re:

[Anonymous Coward]

ここで言う64bitとは整数の型であり、CPUアーキテクチャの64bitとは関係ない

Re:

[Anonymous Coward]

キッチンタイマーはともかく電卓は64bitでもおかしくない 2038年だぜ

Re:

[Anonymous Coward]

いまだって4bitで済むところを8bitどころか
ARMだったりするじゃないか

Re:

[Anonymous Coward]

電球のチップでDoomが動く [theverge.com]世の中だしな

Re:

[Anonymous Coward]

安心どころか人類は何度過ちを繰り返すのかと絶望的になるな。
64bitでは西暦3000億年問題に対応できないんだが、何で不定長にしないのか。

もうすでに問題

[Anonymous Coward]

プログラム何時も今の時刻を扱うとは限らない

1年後の時刻を扱うとなると2037年に

10年後の時刻を扱うとなると2028年に問題が発生する

20年後の時刻を扱うなら、もうすでに問題は発生している。

Re:

[Anonymous Coward]

今の時刻を二つ足して2で割るみたいな操作をしてたせいで不具合になったって
ニュースが報道されたのは相当以前だったよ

Re:

[Anonymous Coward]

2004年に2^30を突破したときのことですね。

【スクープ】コンピュータの“西暦2038年問題”発生、早くも日本を揺るがす
https://xtech.nikkei.com/it/free/NC/NEWS/20040202/139212/ [nikkei.com]

Re:

[Anonymous Coward]

1960年代のプログラム「どうせ2000年まで使われてることなんかありえないし年数とか2桁でええやろ」