Filetime & Sommer/Winterzeit in Linux

[Reinhard]

Hallo, ich habe folgendes problem :

Wenn ich die Uhrzeit einer Datei mittels searchrec.time auslese, erhalte ich die Zeit der letzten Modifikation einer Datei als 64bit integer Zahl.

Das funktioniert soweit auch ganz gut, jedoch nur solange Winterzeit auf dem System eingestellt ist.

Stelle ich heute (06.03.2015) z.b. mit "touch -t 1406061800" die Uhrzeit der Datei auf dem 06.06.2014 18:00 , und frage erneut mittels "findfirst" die Uhrzeit ab bekomme ich 18:00 also die Zeit ohne Sommerzeit (UTC Zeit).

Stimmt alles soweit, um die Zeitverschiebung auf die Sommerzeit anzeigen zu lassen, rufe ich danach "UniversalTimeToLocal(DateTime)" auf welches mir die Zeit unter Berücksichtigung der Winterzeit (GMT+1) um 1 Stunde erhöt also auf 19:00.

Das passt auch alles, jedoch wenn ich jetzt eine Datei mit dem Datum z.b. 06.03.2015 18:00 nehme Erhalt ich trotzdem 19:00 weil die funktion immer 1h dazurechnet.

Wenn ich die Datei im Dolphin ansehe, steht dort auch 18:00 und nicht 19:00.

Irgendwas mach ich da falsch ...

Kann mir da jemand helfen ?

Danke

[theo]

K.A.
Hilft das?
http://wiki.freepascal.org/Daylight_saving_time/de

[Socke]

Stelle ich heute (06.03.2015) z.b. mit "touch -t 1406061800" die Uhrzeit der Datei auf dem 06.06.2014 18:00 , und frage erneut mittels "findfirst" die Uhrzeit ab bekomme ich 18:00 also die Zeit ohne Sommerzeit (UTC Zeit).

In meiner manpage zu touch ist nicht dokumentiert, welche Zeitzone touch -t verwendet. Was passiert denn bei touch -d und welche Ausgabe ergibt ls -l --full-time?

Edit:
Bei mir setzt touch -t die angegebene Zeit passend zur dann gültigen Sommer-/Winterzeit passend zur aktuellen Zeitzone.

Code: Alles auswählen

root:~# touch -t 201404181951.58 testfile
root:~# ls -l --full-time
-rw-r--r-- 1 root root        0 2014-04-18 19:51:58.000000000 +0200 testfile
root:~# touch -t 201401181951.58 testfile
root:~# ls -l --full-time
-rw-r--r-- 1 root root        0 2014-01-18 19:51:58.000000000 +0100 testfile 

[Reinhard]

K.A.
Hilft das?
http://wiki.freepascal.org/Daylight_saving_time/de

Danke hilft zum Teil.

Ich habe die Funktion noch nicht probiert, jedoch stellt sich mir dabei eine grundsätzliche frage :

Sofern das Programm in einem Land läuft das Sommer/Winterzeit hat (hat ja nicht jedes Land) wird es wohl funktionieren, was aber wenn das Programm in einem Land ohne Sommerzeit läuft, die funktion wertet das ja nicht aus.

Ich müsste ja sonnst eine liste machen in welchen Teilen der Welt das Programm läuft damit ich weiß ob ich Sommerzeit/Winterzeit überhaupt auswerten darf.

[Reinhard]

Stelle ich heute (06.03.2015) z.b. mit "touch -t 1406061800" die Uhrzeit der Datei auf dem 06.06.2014 18:00 , und frage erneut mittels "findfirst" die Uhrzeit ab bekomme ich 18:00 also die Zeit ohne Sommerzeit (UTC Zeit).

In meiner manpage zu touch ist nicht dokumentiert, welche Zeitzone touch -t verwendet. Was passiert denn bei touch -d und welche Ausgabe ergibt ls -l --full-time?

Edit:
Bei mir setzt touch -t die angegebene Zeit passend zur dann gültigen Sommer-/Winterzeit passend zur aktuellen Zeitzone.

Code: Alles auswählen

root:~# touch -t 201404181951.58 testfile
root:~# ls -l --full-time
-rw-r--r-- 1 root root        0 2014-04-18 19:51:58.000000000 +0200 testfile
root:~# touch -t 201401181951.58 testfile
root:~# ls -l --full-time
-rw-r--r-- 1 root root        0 2014-01-18 19:51:58.000000000 +0100 testfile 

Ja touch setzt die Uhrzeit korrekt, leider bin ich mir mit "touch" & den dateimanagern bezüglich der "Zeit" nicht einig.

Wie schon erwähnt passt alles sofern es "Winterzeit" ist.

Wenn ich jetzt aber das Datum vorstelle - eben auf derm 06.06. um 18:00 erhalte ich mittels findfirst nicht "18:00" sondern "17:00".

Rufe ich jetzt die funktion "UniversalTimeToLocal(DateTime)" auf stimmt es wieder da die funktion die +1h dazurechnet (abhängig von den System Einstellungen was ich so mitbekommen habe).

Jedoch rechnet die Funktion leider immer die +1h dazu - wenn jetzt Sommerzeit wäre , würde es dann 19:000" heißen was wieder falsch wäre.

Diese "DaylightSaving" Funktion aus dem Wiki sagt ja nur ob Sommerzeit oder Winterzeit ist, (je nach Datum) berücksichtigt aber nicht das jeweilige LAND.

Was noch dazukommt ... was wenn die Sommerzeit abgeschafft wird , dann stimmt das auch in der EU nicht, weil eben stur nach TAG/Monat gefragt wird.

[theo]

Sofern das Programm in einem Land läuft das Sommer/Winterzeit hat (hat ja nicht jedes Land) wird es wohl funktionieren, was aber wenn das Programm in einem Land ohne Sommerzeit läuft, die funktion wertet das ja nicht aus.

Ich müsste ja sonnst eine liste machen in welchen Teilen der Welt das Programm läuft damit ich weiß ob ich Sommerzeit/Winterzeit überhaupt auswerten darf.

Ich habe da auch nicht den Durchblick. In der Unit "unix" gibt es eine boolesche Variable namens "tzdaylight".
Kannst ja mal schauen, ob die funktioniert. Auf Win lässt sich das sicher auch irgendwie herausfinden.
Vielleicht gibt es einen kompatibleren Weg, aber ich kenne ihn nicht.

[Socke]

Ich habe da auch nicht den Durchblick. In der Unit "unix" gibt es eine boolesche Variable namens "tzdaylight".
Kannst ja mal schauen, ob die funktioniert. Auf Win lässt sich das sicher auch irgendwie herausfinden.
Vielleicht gibt es einen kompatibleren Weg, aber ich kenne ihn nicht.

In der Unit SysUtils gibt es die Funktion GetLocalTimeOffset(). Unter Windows scheint sie die Sommerzeit zu berücksichtigen.
Unter Linux wird auf die Variable Tzseconds in der Unit unixutil zurückgegriffen - hier kann ich aber keine Intialisierung erkennen.

Edit: http://lists.lazarus.freepascal.org/pip ... 55568.html - scheint genau dieses Problem zu behandeln

[marcov]

Unter Linux wird auf die Variable Tzseconds in der Unit unixutil zurückgegriffen - hier kann ich aber keine Intialisierung erkennen.

Initialization unit Unix ruft InitLocalTime an, der GetLocalTimeZone anruft der tzseconds setzt.

Ich glaube der Grund das diese Symbolen in Unixutils sind ist weil samt Dos und Sysutils sie benötigen (also die müssen exportiert werden),
aber ich wollte die nicht in der Interface des dokumentierter Unit Unix haben. Also der formell undokumentierter Unixutils war geboren.

[theo]

Habe übrigens noch im Zusammenhang mit diesem Thread diesen Bugreport eingetragen:
http://bugs.freepascal.org/view.php?id=27617

S.a: http://www.freepascal.org/docs-html/rtl ... ltime.html