Java 7 NIO.2 Files.getLastModifiedTime Zeitzone

Question

Ich schreibe ein Programm, das Dateien/Verzeichnisse zuletzt geänderte Zeit bestimmen muss. Ich möchte diese Zeit mit Joda Time behandeln, und ich benutze Java 7 NIO.2 Klasse Files, um die letzte Zeit der Datei zu erhalten. Seine getLastModifiedTime() Methode gibt eine Instanz von FileTime-Klasse, die toMillis() bequeme Methode hat, deren Ergebnis gebe ich zu Joda Zeit DateTime Klassenkonstruktors:

new DateTime(Files.getLastModifiedTime(path).toMillis()); 

jedoch

, habe ich das Gefühl, dass ich das falsch mache, da DateTime(long) Konstruktor erwähnt explizit, dass DateTime Instanz mit Standardzeitzone erstellt wird. FileTime Docs jedoch nicht seine Zeitzone nirgendwo erwähnen. Ich schaute durch FileTime Code; es scheint sehr einfach zu sein, und seine toString() Methode schlägt vor, dass es UTC-Zeitzone verwendet (es erstellt ein Calendar in UTC-Zeitzone und legt seine Millisekunden direkt fest).

Verwendet also FileTime UTC oder lokale Zeit? Was ist der korrekte Weg, um FileTime in DateTime zu konvertieren?

Answer 1

Ein Java-Millisekunden-Zeitstempel ist ein UTC-Zeitstempel. Es ist, was FileTime.toMillis() zurückgibt, und was der DateTime-Konstruktor erwartet. Das Gleiche gilt für andere Java-API-Methoden. z.B. die System.currentTimeMillis() Methode, die java.util.Date Konstruktor, und so weiter.

Sie alle funktionieren auf die gleiche Weise. Und das tun auch andere Unix/Linux/OSX-Bibliotheksmethoden in anderen Programmiersprachen.

Der einzige Fall, in dem dies bricht, ist, wenn jemand die Systemuhr falsch konfiguriert/setzt.

Answer 2

Die API FileTime.toMillis() gibt an, dass sie den Wert in Millisekunden seit der Epoche (1970-01-01T00: 00: 00Z) zurückgibt. new DateTime (millis) erstellt eine DateTime-Instanz, die die Zeit in Millisekunden aus der Java-Epoche von 1970-01-01T00: 00: 00Z und Chronologie in der Standardzeitzone speichert, die bestimmt, wie der Millisekundenwert in die Datumszeitfelder konvertiert wird.