Das 2038-Problem: wie würdet ihr euch vorbereiten?

[Glados]

Aus gegebenem Anlass

Zitat:

Zitat von himitsu (Beitrag 1379904)

PS: Ab dem 19. Januar 2038 um 03:14:08 wird deine Funktion wieder kaputt sein, wenn der Integer zu klein für den Unix-Timestamp ist. :angle:

Wie werdet ihr damit umgehen? Sind wir jetzt mal theoretisch und lassen Sachen wie Rente usw außer acht.
Wie würdet ihr eure Software schon jetzt anpassen, damit ihr nicht von dem Problem betroffen seid?

Ich würde vermutlich vor lauter Dummheit einfach Cardinal nehmen statt Integer. Geht das überhaupt?
Oder aber das ISO 8601 YYYYMMDDHHMMSS-Format.

[Redeemer]

Ich wandle, anders als du, Int64 nicht unnötigerweise in Integer um und lese Compilermeldungen.

[Glados]

Zitat:

Ich wandle, anders als du, Int64 nicht unnötigerweise in Integer um und lese Compilermeldungen.

Ich möchte hier gerne eine friedliche Diskussion führen. Was du hier machst, ist genau das Gegenteil.
Wer bitte sagt denn, dass ich keine Compilermeldungen lese? Wer bitte sagt, dass ich Int64 in Integer umwandle?

Jetzt bitte etwas zum Thema Mister Neunmalklug oder raus hier.

[Ghostwalker]

Ich persönlich verwende inzwischen 64-Bit Integer (Int64). Damit hat man diese Problem erst garnicht. Software, die noch 32-Bit Integer verwendet, würd ich entsprechend auf Int64 anpassen. Das dürfte am wenigsten Aufwand sein, ansonsten müsste man an entsprechenden Stellen eine Umwandlungsfunktion bauen, um sie in ein entsprechendes Format zu bringen.

Was ich bisher zu dem Thema im Internet gelesen habe, ist das auch die Variante, die Empfohlen wird (insbesondere auch bei Web-Apps, die ja sehr häufig mit Unixtimestamps arbeiten).

Gruß

Uwe

[Uwe Raabe]

Was spricht gegen TTimeStamp?

Abgesehen davon arbeitet Delphi bei Unix-TimeStamps doch sowieso schon mit Int64:

Delphi-Quellcode:

{ Unix date conversion support }

function DateTimeToUnix(const AValue: TDateTime; AInputIsUTC: Boolean = True): Int64;
function UnixToDateTime(const AValue: Int64; AReturnUTC: Boolean = True): TDateTime;

[Der schöne Günther]

Das sind noch über 20 Jahre. Ich weiß noch nicht einmal ob mein Kühlschrank-Inhalt bis Samstag reicht, da denke ich über das Ende des Maya-Kalenders oder Unix-Zeitstempels (wenn er signed und 32 Bit ist) ganz sicher nicht nach 8-)

Das als Antwort auf die Frage.

[TiGü]

Glados, was Himi im anderen Thread meinte, war das du für die Umwandlung zwischen Datetime und Unix-Timestamp deine eigenen Funktionen mit Integer als Datentyp nimmst.
Das ist a) sachlich falsch und b) das Rad neu erfunden.

Siehe die von Uwe erwähnten Funktionen in der System.DateUtils:

Delphi-Quellcode:

{ Unix date conversion support }

function DateTimeToUnix(const AValue: TDateTime; AInputIsUTC: Boolean): Int64;
var
  LDate: TDateTime;
 begin
  if AInputIsUTC then
    LDate := AValue
  else
    LDate := TTimeZone.Local.ToUniversalTime(AValue);
  Result := SecondsBetween(UnixDateDelta, LDate);
  if LDate < UnixDateDelta then
     Result := -Result;
 end;

function UnixToDateTime(const AValue: Int64; AReturnUTC: Boolean): TDateTime;
begin
  if AReturnUTC then
    Result := IncSecond(UnixDateDelta, AValue)
  else
    Result := TTimeZone.Local.ToLocalTime(IncSecond(UnixDateDelta, AValue));
end;

[himitsu]

Jupp, ich nehme auch gern für meine Variablen die Typen, welche man bei Parametern und vorallem beim Result raus bekommt ... dann wird auch nichts weggeschnitten :zwinker:

Zitat:

Zitat von Der schöne Günther (Beitrag 1379928)

Das sind noch über 20 Jahre. Ich weiß noch nicht einmal ob mein Kühlschrank-Inhalt bis Samstag reicht, da denke ich über das Ende des Maya-Kalenders oder Unix-Zeitstempels (wenn er signed und 32 Bit ist) ganz sicher nicht nach 8-)

Weißt do noch vor fast 18 Jahren, wo alle Computer auf der Welt abgestürzt sind? :lol:
Damals, in den 80er (20 Jahre vorher) dachte man auch, dass es reicht, wenn man nur die letzten 2 Dezimalstellen des Jahres speichert .... ist ja noch soooo viel Zeit :stupid:

Und sogar jetzt laufen noch sehr viele DOS-Programme, auf irgendwelchen mehr oder weniger wichtigen Systemen.


Du weißt aber, dass im Oktober 2017 der Weltuntergang ist?
Diesmal aber wirklich.

Aber falls nicht, dann 2029, wo so ein kleines Steinchen vom Himmel fällt.
Gut, damit wäre das Problem hier auch erledigt. :)

http://www.stupidedia.org/stupi/Welt...nterg.C3.A4nge
Es gab irgendwo eine Webseite mit einer zuverlässigen Liste aller Termine, aber ich glaub sie ist untergegangen ... find sie nicht mehr.

[HolgerX]

Hmm..

Zitat:

Zitat von Uwe Raabe (Beitrag 1379921)

Abgesehen davon arbeitet Delphi bei Unix-TimeStamps doch sowieso schon mit Int64:

Delphi-Quellcode:

{ Unix date conversion support }

function DateTimeToUnix(const AValue: TDateTime; AInputIsUTC: Boolean = True): Int64;
function UnixToDateTime(const AValue: Int64; AReturnUTC: Boolean = True): TDateTime;

Und dass schon seit Delphi6 (nur ohne UTC) ;)

Delphi-Quellcode:

{ Unix date conversion support }

function DateTimeToUnix(const AValue: TDateTime): Int64;
function UnixToDateTime(const AValue: Int64): TDateTime;

[Glados]

Zitat:

Software, die noch 32-Bit Integer verwendet, würd ich entsprechend auf Int64 anpassen.

Das wäre auch eine Lösung die noch ein paar Jahre hält.
Nutzt du generell Int64 überall oder nur da wo es sein muss?

[Redeemer]

Zitat:

Zitat von Glados (Beitrag 1379908)

Zitat:

Ich wandle, anders als du, Int64 nicht unnötigerweise in Integer um und lese Compilermeldungen.

Ich möchte hier gerne eine friedliche Diskussion führen. Was du hier machst, ist genau das Gegenteil.
Wer bitte sagt denn, dass ich keine Compilermeldungen lese? Wer bitte sagt, dass ich Int64 in Integer umwandle?

Du selbst:

Zitat:

Zitat von Glados (Beitrag 1379896)

Delphi-Quellcode:

function ChangeTime(DateTime: TDateTime; const NewTime: Integer): Integer;
var
 aNewTime: TDateTime;
begin
 if (NewTime >= 86400) or (NewTime <= 0) then // Sicherheitshalber denn sonst gäbe es gar keine Zeitangabe!
  aNewTime := StrToTime('00:00:00')
 else
  aNewTime := SecondsToDateTime(NewTime);

 // bis hier hin ist es noch 23:59:59

 DateTime := RecodeTime(DateTime, System.DateUtils.HourOf(aNewTime), System.DateUtils.MinuteOf(aNewTime), System.DateUtils.SecondOf(aNewTime), 000);
 Result := DateTimeToUnix(DateTime);

 ShowMessage(DateTimeToStr(UnixToDateTime(Result)) + sLineBreak + NewTime.ToString); // Resultat 23:59:58
end;

Der Compiler wird sich darüber beschweren, dass hier eine implizierte Typumwandlung mit Datenverlust auftritt, weil du grundlos Int64 in Integer umwandelst.

Zitat:

Zitat von Glados (Beitrag 1379908)

Jetzt bitte etwas zum Thema Mister Neunmalklug oder raus hier.

Das war zum Thema. Ich habe nur erzählt, wie ich Timestamps in meiner Software verwende, nämlich als Int64, die ich nicht in Integer umwandle. Das wolltest du doch.

[himitsu]

NativeInt statt integer, da wo Integer-Pointer gecastet werden (oder besser IntPtr),
und wo es unter 64 Bit auch 64 Bit sein darf/kann.

Wobei Pointer nicht negativ sind, also UIntPtr/NativeUInt statt Cardinal.

Bei SendMessage/PostMessage wird nicht Integer verwendet, sondern L_PARAM, W_PARAM und L_RESULT.
Also nicht das verwenden, was die Codevervollständigung anzeigt, sondern die "korrekten" Typen, welche oftmals ein Alias sind, aber die Codevervollständigung zeigt immer nur den "aktuellen" Typen an.

[Lemmy]

Himitsu war schneller und sein Text ist besser daher schmeiß ich mein Zeug wieder weg :-)

Zitat:

Zitat von himitsu (Beitrag 1379948)

Also nicht das verwenden, was die Codevervollständigung anzeigt, sondern die "korrekten" Typen

Zitat:

Zitat von Redeemer (Beitrag 1379945)

Du selbst:

falls jemand den Ursprungsthread nicht kennt: http://www.delphipraxis.net/193692-e...-sekunden.html

[Glados]

Ich würde gerne beim Thema bleiben.
Der Ursprungsthread hat nichts mit diesem hier zu tun.

Dieser Thread hat sich für mich jedenfalls erledigt, wenn man nicht beim Thema bleiben kann.
Ich bin raus.

[Daniel]

Wir sind bei Deinem Thema. Der Schlüssel liegt in den 64 Bit Datentypen.

[Lemmy]

Zitat:

Zitat von Glados (Beitrag 1379950)

Ich würde gerne beim Thema bleiben.
Der Ursprungsthread hat nichts mit diesem hier zu tun.

doch, denn Redeemer hat daraus zitiert. Und damit da nicht jeder, der sich informieren will selbst suchen muss, habe ich den Link hier eingefügt, das sollte man bei Zitaten eigentlich machen....

[Redeemer]

Man kann auf "Zitat von ..." klicken.

[himitsu]

Zitat:

Zitat von Redeemer

Man kann auf "Zitat von ..." klicken.

Nicht immer.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1379948)

Also nicht das verwenden, was die Codevervollständigung anzeigt, sondern die "korrekten" Typen, welche oftmals ein Alias sind, aber die Codevervollständigung zeigt immer nur den "aktuellen" Typen an.

FWIW: RSP-17110

[samso]

Bei mir gibt es zwei Gründe weshalb ich überhaupt das Unixdatumsformat verwende:

1. das extern verwendete Datumsformat ist das Unixformat
2. ich möchte ein kompaktes Format für Datum+Uhrzeit verwenden (d.h. Speicherplatz sparen)

Bei dem ersten Punkt bereite ich mich nicht vor, sondern passe mich dann an, wenn sich das externe Format ändert.
Bei dem zweiten Punkt hängt es davon ab, ob ich den Aspekt der Speicherersparnis noch zeitgemäß finde. Wenn das nicht der Fall ist, wähle ich bei dem Wechsel auf 64 Bit ein anderes Datenformat (z.B TDateTime, TTimestamp oder TFiletime).