Delphi-PRAXiS - Verdammt gute Kalenderfrage

Das kommt drauf an.
Negative Werte gibt es ja nicht immer.

Delphi nutzt standardmäßig TDateTime, was intern die Zeit über einen TSystemTime holt. ( Delphi-Referenz durchsuchen

Now /

GetSystemTime)
TDateTime ist ein Double und da gibt es negative Werte.
TSystemTime ist ein Record aus Words und da kann man nur bis zum Jahr 0 runter, also ein Jahr, bevor der eine Typ angeblich geboren wurde.

Im negativen Bereich ist Delphi-Referenz durchsuchen

TDateTime bissl "gemein", also bei Überschreitung der Grenze unbedingt die OH lesen!

Und nun zum Linux / Unix Timestamp, denn da könnte man den Wert (Sekunden) in einem Integer mit oder ohne Vorzeichen speichern (LongInt oder LongWord).
Da Linux im Jahre 2038 ein Problem bekommen soll, werden sie wohl meistens mit einem signed Integer rechnen und dann gibt es auch ein negatives davor.

2017-01-06 00:00:00 (1483660800)
2038-01-19 03:14:07 ($7FFFFFFF)
2106-02-07 06:28:15 ($FFFFFFFF)

Nur wie man das da mit den Schaltdekunden machen will ... Linux muß dann doch jede einzelne Schaltsekunde kennen und wenn dann mal jemand "unerwartet" daran was ändert....
Und bei der Umrechnung muß man dann auch noch alle Zeitverschiebungen einberechnen. :shock: Ich glaub mit einer extrem kranken mathematischen Formel läßt sich das nicht gut berechnen.

Delphi-Quellcode:

			TSystemTime = record  // 16 Byte (4 Integer)

  wYear: Word;

  wMonth: Word;

  wDayOfWeek: Word;

  wDay: Word;

  wHour: Word;  // 0 bis 65.535 Uhr :lol:

  wMinute: Word;

  wSecond: Word;

  wMilliseconds: Word;

end;

// Ich hätte es ja eher so definiert, aber k.A. was sich der bei Microsoft damals dabei gedacht hat oder ob er nichts dachte, aber ganze Integer wären auch ein Grund.

TSystemTime = record  // 10 Byte

  wYear: Word;

  wMonth: Byte;

  wDayOfWeek: Byte;

  wDay: Byte;

  wHour: Byte; // 0 bis 255 Uhr, aber halbe Bytes sind ja blöd

  wMinute: Byte;

  wSecond: Byte;

  wMilliseconds: Word;

end;