Zeitfehler mit lastModified() und setLastModified()

[gschmi01]

Hallo

Ich verwende die genannten Methoden, um Änderungsdatum und -zeit einer Datei zu lesen und zu setzen. Dabei treten 2 Probleme auf.

Lesen von Änderungsdatum und -zeit:

        DateFormat df = DateFormat.getDateTimeInstance(DateFormat.MEDIUM, DateFormat.MEDIUM, Locale.GERMANY);
        File file = new File("C:\\test.txt");
        String datumZeit = new String(df.format(new Date(file.lastModified())));

Effekt:
Für eine Datei mit dem Änderungszeitpunkt 30.11.2008 11:41:17 laut Datei-Explorer wird mit dem heutigen Tag ein Änderungszeitpunkt von 30.11.2008 10:41:17 ermittelt, also 1h älter. Das könnte mit der Sommer- bzw. Winterzeit zusammenhängen. Leider konnte ich in der API für die Klassen Date und DateFormat nichts finden, um den Effekt zu korrigieren.


Setzen von Änderungsdatum und -zeit:

        Calendar cal = Calendar.getInstance(););
        cal.set(2008, 10, 30, 11, 50, 0);  // 30.11.2008 11:50:00    Monate 0...11 !);
        long milliSeconds = cal.getTimeInMillis(););
        File file = new File("C:\\test.txt"););
        file.setLastModified(milliSeconds);

Hier wird der Änderungszeitpunkt auf 30.11.2008 12:50:02 gesetzt. Also wieder eine Stunde Versatz (dieses Mal in die andere Richtung) und noch 2 Sekunden dazu.

Kennt jemand eine Lösung für den Zeitversatz von 1h und den 2 Sekunden?
Wäre super!

Hinweis: Ich verwende Win98SE und JDK1.5.0_16.

Viele Grüße
gschmi01

 

[Spacerat]

Sommerzeit Gute Idee...
Könnte aber auch daran liegen, dass das Datum in der Datei möglicherweise in GMT gespeichert und zur Anzeige mit der Systemzeit verrechnet wird. Lässt sich sogar nachvollziehen, indem man in Windows sich die Daten einer Datei ansieht, die Zeitzone ändert, und anschliessend die Daten vergleicht. Für die 2 sekunden habe ich allerdings keine Erklärung.

 

[eRaaaa]

Für die 2 sekunden habe ich allerdings keine Erklärung.

liegt vermutlich am dateisystem. bei fat32 soll das wohl vorkommen.
bei ntfs dürftest du die probleme nicht haben.

 

[musiKk]

liegt vermutlich am dateisystem. bei fat32 soll das wohl vorkommen.

FAT32 hat in der Tat nur eine Auflösung von 2 Sekunden.

 

[gschmi01]

Hallo Spacerat

Ich habe die betreffende Datei mit einem HEX-Editor geprüft. Es ist keine Zeitinformation darin enthalten. Diese muß in der Ordner/Datei-Information in NTFS/FAT enthalten sein. Bei einer Umstellung der Zeitzone (GMT 01:00 --> GMT 02:00) geht die im Explorer angezeigte Dateizeit auch entsprechend mit (11:02 --> 12:02), ohne daß die Datei physisch verändert wird. Dieser Ansatz hilft mir/uns nicht weiter.

Viele Grüße
gschmi01

 

[gschmi01]

Hallo musiKk

Danke für den Hinweis mit der 2-Sekunden-Auflösung!!
Da mein Win98SE mit FAT arbeitet, muß das wohl der Grund sein. Ich werde mich in der Java-Programmierung danach richten. ;-)

Viele Grüße
gschmi01


PS: Dann bleibt "nur" noch die Sache mit 1h Zeitversatz offen.

 

[eRaaaa]

hä?
das check ich jetzt aber auch nicht ???:L

cal.set(2009,10,22,0,9,0);
		System.out.println(cal.getTimeInMillis()); //1 //1 std versatz
		System.out.println(cal.getTimeInMillis()-(60*60*1000)); //2  //richtig
		System.out.println(System.currentTimeMillis());  //3  // richtig
		long milli = cal.getTimeInMillis()-(60*60*1000);
		file.setLastModified(milli);

liefert mir ca. um 00:09 (+paar sek)
folgendes

[1]1258844940328 //cal.getTimeInMillis()
[2]1258841340328 // (cal.getTimeInMillis()-(60*60*1000))
[3]1256163022328 //System.currentTimeMillis()

das komische ist
a) so funktioniert es (also lastmodified wird so richtig gesetzt, also so wie angegeben)
aber...
b) setlastmodified(System.currentTimeMillis()) funktioniert ja normalerweise auch so wie es soll

aber die differenz zwischen diese beiden ist ja viel höher, als zwischen [1] und [2] ?! (wobei da ja die 1 std versatz ist) ???:L???:L

bug? einfache erklärung? ich geh jetzt jedenfalls ins bett

 

[Spacerat]

@TS: Natürlich liegen die Zeiten im jeweiligen Verzeichniseintrag einer Datei. Mit 'nem ordinären Hexeditor wird man da nicht viel reissen. Da bräuchte man schon so 'ne Art DiskMonitor.
Aber das hilft ja auch nicht weiter. Was man mal ausprobieren müsste, eine Beliebige Zeit in GMT erstellen und für die Datei speichern. Anschliessend diese Zeit in die Systemzeitzone wandeln und vergleichen.
Aufgrund von eRaaas Test ist auch anzunehmen, das "cal.getTimeInMillis()" die Zeit standardmässig in GMT zurückgibt. Hat der Kalender zufällig eine Möglichkeit eine TimeZone zu setzen?

 

[musiKk]

Aufgrund von eRaaas Test ist auch anzunehmen, das "cal.getTimeInMillis()" die Zeit standardmässig in GMT zurückgibt. Hat der Kalender zufällig eine Möglichkeit eine TimeZone zu setzen?

[c]setTimeZone()[/c] klingt ganz gut. Eigentlich sollte das aber nicht nötig sein, da Calendar bei jeder Erzeugung, bei der die TimeZone nicht explizit angegeben wird, mit der des Systems initialisiert wird. Bei mir gibt [c]System.currentTimeMillis()[/c] und [c]Calendar.getInstance().getTimeInMillis()[/c] auch das gleiche zurück. Die Werte sind dabei auch alle lokal, also die Zeitzone steht auf "Europe/Berlin".

Naja, am Sonntag wird mit der Winterzeit wieder alles anders. Die FDP wirds bis dahin wahrscheinlich nicht schaffen, die Zeitumstellung zu beseitigen.

 

[Spacerat]

Das ist mal ein Merksatz:

Wenn ich während der Sommerzeit ein Dateidatum in der Winterzeit oder umgekehrt setze, bekomme ich eine Stunde versatz.

Klingt auch iwie logisch, wenn man drüber nachdenkt. Denn wenn es anders wäre, müssten die Daten sämtlicher Dateien auf der Platte geändert werden, wenn die Zeitzone umgestellt wird, damit sie stets korrekt angezeigt werden. Die Daten vom TS werden also korrekt gesetzt und müssen deswegen gar nicht korregiert werden.

Möchte man es dennoch tun:

// ungetestet
cal.set(DST_OFFSET, 0);

 

[gschmi01]

Hallo Spacerat

Danke für Deinen letzten Beitrag, ich werd's beachten.

Viele Grüße
gschmi01