Bug oder Feature?

[foofoobar]

Bug oder Feature?

$ date --date=\@$((2**31))
Tue Jan 19 04:14:08 CET 2038
$ date --date=\@$((2**55))
Sun Jun 13 07:26:08 AM CET 1141709097
$ date --date=\@$((2**56))
date: time ‘72057594037927936’ is out of range
$

 

[Linuxfreakgraz]

Warum will man das Datum auf die Zukunft stellen?

 

[oicfar]

https://de.wikipedia.org/wiki/Jahr-2038-Problem ?

Ergänzung (Heute um 14:25)

Das liegt nicht am 2038-Problem, sondern sehr wahrscheinlich daran, dass GNU date intern irgendwann einen Kalenderwert in eine struct tm umrechnen muss. Dort ist tm_year typischerweise ein int, also ungefähr auf Jahre bis rund 2,1 Milliarden begrenzt.

Ergänzung (Heute um 14:27)

https://man7.org/linux/man-pages/man0/time.h.0p.html -> nach int tm_year Years since 1900. suchen.

 

[foofoobar]

https://man7.org/linux/man-pages/man0/time.h.0p.html -> nach int tm_year Years since 1900. suchen.

Ok, thx, das passt.
Ich fand die Entscheidung auf 64-Bit Systemen int auf 32-Bit zu stellen schon immer dämlich.

 

[Perdakles]

Ich fand die Entscheidung auf 64-Bit Systemen int auf 32-Bit zu stellen schon immer dämlich.

„640K of RAM ought to be enough for anybody“

So ähnlich dachte man dann wohl auch was den int-Typen auf 64-Bit Systemen angeht.