2009-10-04 4 views
23

Ho 2 computer diversi, ciascuno con TimeZone diverso.java.util.Date utilizza TimeZone?

In stampa System.currentTimeMillis() un im computer, quindi stampa il seguente comando in entrambi i computer: System.out.println(new Date(123456)); -> 123456 indica il numero è venuto nel currentTimeMillis nel computer # 1.

La seconda stampa (anche se digitata con hardcoded) genera stampe diverse, su entrambi i computer. perché è quello?

risposta

48

Che ne dici di alcuni dettagli pedanti.

java.util.Date è indipendente dal fuso orario. Dice così bene nel javadoc.

Vuoi qualcosa in relazione a un determinato fuso orario? Questo è java.util.Calendar.

La parte difficile? Quando si stampa questa roba (con java.text.DateFormat o subclass), ciò implica un Calendario (che coinvolge un fuso orario). Vedi DateFormat.setTimeZone().

Sembra sicuro (non ha controllato l'implementazione) come java.util.Date.toString() passa attraverso un DateFormat. Quindi anche la nostra classe (per lo più) indipendente dal fuso orario si incasina w/timezones.

Vuoi ottenere quella roba del fuso orario dai nostri oggetti Date senza zoneless? C'è Date.toGMTString(). Oppure puoi creare il tuo SimpleDateFormatter e usare setTimeZone() per controllare quale zona è usata tu stesso.

+0

java.util.Date è solo un po 'indipendente dal fuso orario. Copia e incolla da Java SDK7 java.util.Date.toString() 'TimeZone zi = date.getZone(); if (zi! = Null) { sb.append (zi.getDisplayName (date.isDaylightTime(), zi.SHORT, Locale.US)); // zzz } else { sb.append ("GMT"); } '' date' è un 'BaseCalendar' il cui fuso orario è impostato su' TimeZone.getDefaultRef() ' –

+1

Il punto chiave è che stai parlando del metodo toString(). Ho detto che non avevo guardato all'implementazione di toString(), ma sospettavo che riguardasse un calendario. L'hai appena confermato. Nessun disaccordo tra di noi. –

+1

L'oggetto 'Date' funziona con un membro' cdate' (che è un 'BaseCalendar') con un fuso orario. E poi succedono cose alle quali nessuno importa davvero e 'Date' si comporta indipendente dal fuso orario finché non lo stampi. Non intendevo contraddire la tua risposta. –

5

Poiché il numero di millisecondi corrisponde al numero di millisecondi precedenti all'1/1/1970 UTC. Se poi si traduce in un fuso orario diverso, il tempo di rendering sarà diverso.

ad es. 123456 potrebbe corrispondere al mezzogiorno di Greenwich (UTC). Ma quello sarà un tempo diverso a New York.

Per confermare, utilizzare SimpleDateFormat con un fuso orario di uscita e/o modificare il fuso orario sul secondo computer in modo che corrisponda al primo.

5

perché è quello?

Perché qualcosa come "4 ottobre 2009, 14:20" non ha senso senza conoscere il fuso orario si riferisce a - che si può più probabile vedere in questo momento, perché questo è il mio tempo mentre scrivo questo, e probabilmente differisce da molte ore dal tuo tempo anche se è lo stesso momento nel tempo.

I timestamp del computer sono generalmente misurati in UTC (in pratica il fuso orario di Greenwich, Inghilterra) e il fuso orario deve essere preso in considerazione quando li si formatta in qualcosa di leggibile.

+1

So che questo è un thread vecchio, ma ho dovuto votare per la tua spiegazione/dichiarazione del motivo per cui la data senza timezone non ha senso. –

+1

@HelterScelter Devo downvotare la stessa cosa. È come dire che la massa non ha senso senza la costante di gravità. Sono entrambi significativi a modo loro. –

2

javadoc spiega bene, System.currentTimeMillis() nota che mentre l'unità di tempo del valore di ritorno è un millisecondo, la granularità del valore dipende dal sistema operativo sottostante e può essere superiore. Ad esempio, molti sistemi operativi misurano il tempo in unità di decine di millisecondi.