Unix sysutils.findfirst falsches Datum 2025 31 Uhr
-
- Beiträge: 142
- Registriert: Sa 30. Jan 2010, 19:35
- OS, Lazarus, FPC: Linux64, Wiindows32, MacOS, Lazarus 1.8.2
- CPU-Target: xxBit
Unix sysutils.findfirst falsches Datum 2025 31 Uhr
Wenn ich sysutils.findfirst verwende, erhalte ich bei der Abfrage von tSearchrec.time, wenn ich sie unpacke, bei MacOS wirre Datumsangaben (2025, 31 Uhr). Unter Windows geht es. Ich habe auf die aktuelle Freepascal/Lazarus Version upgegradet. Kennt jemand dieses Problem?
-
- Lazarusforum e. V.
- Beiträge: 999
- Registriert: Do 17. Apr 2008, 01:59
- OS, Lazarus, FPC: Mint 21.1 Cinnamon / FPC 3.2.2/Lazarus 2.2.4
- CPU-Target: Intel i7-10750 64Bit
- Wohnort: Freiburg
Re: Unix sysutils.findfirst falsches Datum 2025 31 Uhr
Ist doch klar, wenn die Sommerzeit in zwei Jahren abgeschafft wird, also 2020, dann verschiebt sich die Zeit ja jedes Jahr um 1 Stunde. Das macht schon mal 5 Stunden, womit der Tag sich von heute 24 Stunden +5 auf 29 Stunden verlängert. Dann haben wir ja ohnehin noch zwei Stunden Zeitverschiebung - et voila:
Im Jahr 2025 ist 31 Uhr durchaus möglich.
Warum die bei Linux und MS das noch nicht implementiert haben, ist allerdings auch mir ein Rätsel
PS: Sorry
Im Jahr 2025 ist 31 Uhr durchaus möglich.

Warum die bei Linux und MS das noch nicht implementiert haben, ist allerdings auch mir ein Rätsel



PS: Sorry

Alle sagten, dass es unmöglich sei - bis einer kam und es einfach gemacht hat.
-
- Beiträge: 2120
- Registriert: Di 23. Sep 2014, 17:46
- OS, Lazarus, FPC: Win10 | Linux
- CPU-Target: x86_64
Re: Unix sysutils.findfirst falsches Datum 2025 31 Uhr
Da müsste man mal an sich schauen wie findfirst für OSX implementiert ist. An sich müsste das ja auf die selben POSIX Funktionen wie unter Linux zurückgreifen. Ich geh einfach mal davon aus das die OSX implementiereung "vergisst" stat aufzurufen für die zusätzlichen Informationen wie zeit zu erhalten (im Gegensatz zur windows API gibt die readdir Funktion nicht die Dateizeit zurück). Mach doch ein {$IFDEF UNIX} mit der Funktion stat.
-
- Beiträge: 142
- Registriert: Sa 30. Jan 2010, 19:35
- OS, Lazarus, FPC: Linux64, Wiindows32, MacOS, Lazarus 1.8.2
- CPU-Target: xxBit
Re: Unix sysutils.findfirst falsches Datum 2025 31 Uhr
Inzwischen habe ich das Programm auch unter Linux 64 bit compiliert, auch hier verhält es sich so wie bei MacOS. Es ist also Unix-spezifisch. Das kann doch nicht sein, dass noch keiner solch einen Fehler bemerkt hat? Gibt es noch eine Alternative zu sysutils.findfirst und Konsorten?
Re: Unix sysutils.findfirst falsches Datum 2025 31 Uhr
Was machst du konkret?Martin V hat geschrieben:Wenn ich sysutils.findfirst verwende, erhalte ich bei der Abfrage von tSearchrec.time, wenn ich sie unpacke, bei MacOS wirre Datumsangaben (2025, 31 Uhr). Unter Windows geht es. Ich habe auf die aktuelle Freepascal/Lazarus Version upgegradet. Kennt jemand dieses Problem?
Folgendes zeigt bei mir (Mint, Laz trunk) die aktuelle Zeit an:
Code: Alles auswählen
uses
DateUtils;
procedure TForm1.Button1Click(Sender: TObject);
var
Info: TSearchRec;
t: TDateTime;
s: String;
ft: LongInt;
begin
If FindFirst ('*',faAnyFile and faDirectory,Info)=0 then
begin
Repeat
With Info do
s := Format('%s - %s', [
Info.Name,
FormatDateTime('dd.mm.yyyy hh:nn', UniversalTimeToLocal(UnixToDateTime(Info.Time)))
]);
Memo1.Lines.Add(s);
Until FindNext(info)<>0;
end;
FindClose(Info);
end;
-
- Beiträge: 142
- Registriert: Sa 30. Jan 2010, 19:35
- OS, Lazarus, FPC: Linux64, Wiindows32, MacOS, Lazarus 1.8.2
- CPU-Target: xxBit
Re: Unix sysutils.findfirst falsches Datum 2025 31 Uhr
Danke für den richtigen Hinweis. Ich habe jetzt herausgefunden, dass das interne longint Zeitformat aus dem tSearchRec bei Windows und Unix verschieden ist. PackTime und UnpackTime darf man nur bei Windows verwenden, bei Unix muss man stattdessen UnixDateToDT und DTtoUnixDate verwenden. In der Doku steht zwar, man soll die Funktionen nicht direkt aufrufen, aber die generelle plattformunabhängige Prozedur dafür habe ich nicht gefunden.