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
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
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:
- Arnd Bergmann’s kernel patches (most of which are merged or close to being merged, as of version 5.1 of the kernel),
- Albert Aribaud’s
glibcpatches (based on the design outlined here),
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.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0