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

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