4

I am curious why a signed integer value was used to hold Unix time. It clearly would have made significantly more sense to use an unsigned integer as time can't go backwards, so having a negative value for time is, well, impossible. However, on January 19, 2038 Unix time will overflow and it will be the end of time as many of us know it. We will go from 2,147,483,647 to -2,147,483,648... Not good.

So, why was a signed integer used and how hard would it be to implement a fix for this when the end of time does come near?

Ingenioushax
  • 143
  • 4
    This might be related. – taliezin Aug 18 '16 at 17:56
  • That pretty well answers my question. However, what about the older mission critical systems and early RTOS based systems that still use a signed 32-bit integer value? How would they handle this problem? – Ingenioushax Aug 18 '16 at 17:59
  • It clearly would have made significantly more sense to use an unsigned integer as time can't go backwards. No, because obviously you'd want to be able to represent dates before 1970 (eg birthdays of anyone alive at the start of the epoch) or durations/changes in time (eg Then - Now = -5 sec). – Benny Jobigan Apr 24 '20 at 02:18

1 Answers1

2

OpenBSD some time ago moved from a 32 to a 64 bit time value, which gives some breathing room to the end of time thing. How hard this fix will be will depend on the unix and how well supported it is (and how close to 2038 time moves).

% date -r $((2**31))
Tue Jan 19 03:14:08 GMT 2038
% date -r $((2**51))
Mon Jun 19 13:54:08 GMT 71358665
thrig
  • 34,938
  • Very nice. OpenBSD had some foresight :) – Ingenioushax Aug 18 '16 at 18:18
  • 1
    @Ingenioushax well applications that assume 32-bit on OpenBSD will be buggy, but that's a porting issue... – thrig Aug 18 '16 at 18:43
  • 1
    (1) On my system, those commands fail; I have to use date -d @$((2**31)), etc. (2) As noted by freiheit, this fails at date -d @$((2**56)) because that puts the year ≥ 2147483648 (2³¹). To play with this, try date -d @$((60*2**50)) and date -d @$((61*2**50)). (Interestingly, freiheit reports getting −2147483648 as the year, whereas I get “date: time 68679894317400064 is out of range”.) – Scott - Слава Україні Aug 18 '16 at 18:46