9

I wrote a little bash script that made me stumble across the "Year 2038 Bug". I did not know about this problem before and I just dare on posting the --debug output I got from date when my script tried to calculate across this magic date (03:14:07 UTC on 19 January 2038).

date -d "20380119"

date: parsed number part: today/this/now
date: input timezone: +01:00 (set from system default)
date: warning: using midnight as starting time: 00:00:00
date: starting date/time: '(Y-M-D) 2038-01-19 00:00:00 TZ=+01:00'
date: '(Y-M-D) 2038-01-19 00:00:00 TZ=+01:00' = 2147468400 epoch-seconds
date: output timezone: +01:00 (set from system default)
date: final: 2147468400.000000000 (epoch-seconds)
date: final: (Y-M-D) 2038-01-18 23:00:00 (UTC0)
date: final: (Y-M-D) 2038-01-19 00:00:00 (output timezone TZ=+01:00)
Tue Jan 19 00:00:00 CET 2038

date -d "20380119 + 1 days"

date: parsed hybrid part: +1 day(s)
date: input timezone: +01:00 (set from system default)
date: warning: using midnight as starting time: 00:00:00
date: starting date/time: '(Y-M-D) 2038-01-19 00:00:00 TZ=+01:00'
date: warning: when adding relative days, it is recommended to specify 12:00pm
date: error: adding relative date resulted in an invalid date: '(Y-M-D) 2038-01-20 00:00:00 TZ=+01:00'
date: invalid date '20380119 + 1 days'

date -d "20380120" --debug

date: parsed number part: today/this/now
date: input timezone: +01:00 (set from system default)
date: warning: using midnight as starting time: 00:00:00
date: error: invalid date/time value:
date:     user provided time: '(Y-M-D) 2038-01-20 00:00:00 TZ=+01:00'
date:        normalized time: '(Y-M-D) 2038-01-20 00:00:00 TZ=+01:00'
date: 
date:      possible reasons:
date:        numeric values overflow;
date:        missing timezone
date: invalid date '20380120'

Is there any way to make GNU date calculate across this date?
(on a LINUX 32 bit system)

  Operating System: Debian GNU/Linux buster/sid
            Kernel: Linux 4.12.0-2-686-pae
      Architecture: x86
14

If you want to stick to GNU date on 32-bit Linux, there’s no easy way to get it to work with dates after 2038. The coreutils maintainers don’t consider this a coreutils bug, so don’t expect a fix there — the fix will have to come from the C library and the kernel. If you want to play around with the work in progress, you’ll need:

and a decent amount of skill and patience.

For more on the way 2038 was planned to be handled in the 32-bit Linux world, see LWN and the write-up of the 2038 BoF at DebConf 17 (with the follow-up comments there and on LWN). This January 2019 LWN article describes the changes which are being implemented in the kernel.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.