アカウント名:
パスワード:
まぁ主な問題は各種プロトコルやファイルフォーマットで 32bit な UNIX 時間が使われていることですね。
#ネタ元を知ってて言ってると理解していますが。
一応解説するとFAT の修正時刻のタイムスタンプは2秒単位です。んでもって、いわゆる UNIX 時間ではありません。
Windowsの標準機能でZip圧縮・展開して奇数秒が丸められても誰も気にしていないようだから、それほど荒唐無稽な話でもないんじゃね。# NTFS拡張レコードの記録に対応した圧縮ツールを使っても、Windowsの標準機能で展開すると拡張レコードは無視されるので、やっぱり奇数秒は丸められる。
time_t の実態が 32bit の符号付き整数であるにも関わらず内部では符号なし実数として扱っているのでした。
((~ (time_t) 0) (time_t) 0) = 10x80000000 = 2038-01-19 03:14:08 UTC0xFFFFFFFFF = 2106-02-06 06:28:15 UTC
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
64bit time_t で解決でなく対応の始まり (スコア:2)
Re: (スコア:1)
まぁ主な問題は各種プロトコルやファイルフォーマットで 32bit な UNIX 時間が使われていることですね。
[Q][W][E][R][T][Y]
Re:64bit time_t で解決でなく対応の始まり (スコア: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