Datum - Jahre vor 1901 werden als ungültig behandelt

11

Ich habe Datum (GNU coreutils) 7.1 auf meinem System installiert.

Wenn ich versuche, Daten vor dem 14. Dezember 1901 zu überprüfen, wird der Fehler "Ungültiges Datum" angezeigt. Beispielsweise,

  $ date -d 1901-12-13
  date: invalid date `1901-12-13'

  $ date -d 1901-12-14
  Sat Dec 14 00:00:00 EST 1901

Was soll ich tun, damit das dateDienstprogramm Jahre vor 1901 als gültig behandelt?

Ich erhalte ähnliche Fehler für Daten nach dem 19. Januar 2038

shell-script date

— Jasdeep Singh
quelle

Ich erhalte keinen Fehler. Ich benutze Coreutils 8.10, vielleicht ein alter Fehler?

— Xenoterracide

@ Xenoterracide Sind Sie ein 64-Bit-System?

— Mikel

@Mikel ja, ich bin

— Xenoterracide

15

Gute Frage.

Die Dokumentation sagt, dass es erlaubt sein sollte.

 info date 'Date input formats' 'Calendar date items'

Für numerische Monate ist das ISO 8601-Format "JAHR-MONAT-TAG" zulässig, wobei JAHR eine beliebige positive Zahl ist, ...

Eine führende Null muss vorhanden sein, wenn eine Zahl kleiner als zehn ist.

Wenn YEAR 68 oder kleiner ist, wird 2000 hinzugefügt. Wenn andernfalls JAHR weniger als 100 beträgt, wird 1900 hinzugefügt.

Sind Sie auf einem 32-Bit-System?

Erhalten Sie auch einen Fehler mit Daten nach 2038-01-20, z

date -d '2038-01-20'

In diesem Fall verwendet das GNU-Datum einen 32-Bit-Zeitwert.

Ich bin mir nicht sicher, wie Sie dies beheben können, außer mit einem 64-Bit-System oder einem anderen Tool, z. B. DateTime in Perl oder datetime in Python.

Einige Hintergrundinformationen:

Unix-Zeiten zählen die Anzahl der Sekunden ab dem 1. Januar 1970 mit einem ganzzahligen Wert. Wenn das System 32-Bit-Ganzzahlen verwendet, kann es nur 2,1 Milliarden Sekunden vorwärts (bis 2038-01-19 03:14:02 UTC) und 2,1 Milliarden Sekunden rückwärts (zurück bis 1901-12-13 20:45:52) zählen KOORDINIERTE WELTZEIT).

Weitere Informationen unter:

— Mikel
quelle

Danke Mikel, ich glaube, dass ich auf einer 32-Bit-Maschine bin. Eigentlich arbeite ich auf einem Remote-Server und der Server wird selbst mit unameBefehl nicht viele Informationen preisgeben, außer der Tatsache, dass es sich um einen i686-Computer handelt, von dem ich annehme, dass es sich um 32-Bit-Computer handelt. Was das 2038-Problem betrifft, ja, dieses Problem ist tatsächlich auf dem Remote-Server vorhanden. Nochmals vielen Dank für Ihre Eingabe! Sehr geschätzt !!

— Jasdeep Singh

Ja, i686 ist 32-Bit. Froh, dass ich Helfen kann. Wenn Sie Hilfe beim Umgang mit älteren Daten benötigen, probieren Sie die von mir vorgeschlagenen Python- und Perl-Module aus und stellen Sie eine weitere Frage, wenn Sie sie nicht zum Laufen bringen können.

— Mikel

7

Ihr System (oder zumindest diese Datumsversion ) verwendet wahrscheinlich einen internen 32-Bit-Zeitwert.

Die Unix-Epoche (Zeitwert Null) ist 1970-01-01 00:00:00 UTC. Dieser Startpunkt liegt zwischen 1901-12-13 00:00 EST knapp außerhalb des Bereichs eines vorzeichenbehafteten 32-Bit-Zeitwerts.

1901-12-14 00:00:00 EST ist -2147454000
1901-12-13 15:45:52 EST ist -2147483648 (auch bekannt als INT_MINin C, die minimale 32-Bit-Ganzzahl mit Vorzeichen)
1901-12-13 00:00: 00 EST ist -2147540400

Sie könnten versuchen, 1901-12-13 15:45:52 EST zu verwenden. Es sollte funktionieren, aber eine Sekunde früher wird wahrscheinlich genauso scheitern wie 1901-12-13 00:00.

— Chris Johnsen
quelle