Bash - date, aggirando il bug 2038 sul sistema LINUX a 32 bit

Ho scritto un piccolo script bash che mi ha fatto inciampare in "Bug 2038 anno" . Prima non sapevo di questo problema e ho solo il coraggio di pubblicare l' --debugoutput che ho ricevuto da datequando la mia sceneggiatura ha cercato di calcolare questa data magica (03:14:07 UTC il 19 gennaio 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'

C'è un modo per datecalcolare GNU attraverso questa data?
(su un sistema LINUX a 32 bit)

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

linux date gnu

— nath
fonte

Un modo per aggirarlo nei sistemi a 32 bit è usare un sistema operativo * BSD.

— Rui F Ribeiro,

Non bash ma: search.cpan.org/~mschwern/Time-y2038-20100403/lib/Time/y2038.pm

— jesse_b

@Kusalananda scusa per non essere chiaro. Sì, sto chiedendo un modo per GNU date. Modificherò la mia domanda ...

— Nath,

FWIW, OpenBSD ha risolto questo problema nel 2014 . Ha funzionato molto, ma in qualche modo sono riusciti a correggere tutti i bit rilevanti.

— Satō Katsura,

@RuiFRibeiro Non esattamente vero: time_t è 8 byte su tutte le architetture supportate tranne i386 .

— Isaac,

Se si desidera attenersi a GNU datesu Linux a 32 bit, non esiste un modo semplice per farlo funzionare con date successive al 2038. I coreutilsmanutentori non lo considerano un coreutilsbug , quindi non aspettarsi una correzione lì - la correzione avrà proveniente dalla libreria C e dal kernel. Se vuoi giocare con i lavori in corso, avrai bisogno di:

Le patch del kernel di Arnd Bergmann (la maggior parte delle quali sono unite o quasi unite, a partire dalla versione 5.1 del kernel),
Le glibcpatch di Albert Aribaud (basate sul design delineato qui ),

e una discreta quantità di abilità e pazienza.

Per ulteriori informazioni sul modo in cui è stato pianificato di gestire il 2038 nel mondo Linux a 32 bit, vedere LWN e la redazione del BoF 2038 su DebConf 17 (con i commenti di follow-up lì e su LWN ). Questo articolo LWN di gennaio 2019 descrive le modifiche che vengono implementate nel kernel.

— Stephen Kitt
fonte