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

[Redeemer]

Zitat von 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?

Du selbst:

Zitat von Glados:

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 von Glados:

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 von himitsu:

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

Zitat von Redeemer:

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 von Glados:

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 von Redeemer:

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

Nicht immer.

[Stevie]

Zitat von himitsu:

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).