2013-06-23 9 views
5

Ho bisogno di aiuto. Ho cercato di capire perché la data java util è 5 ore indietro dopo la conversione da tick C#.C# Ticks convertono in data java; la data è 5 ore dietro perché?

in C#, la data è il 6/8/2013 alle 11:02:07, ho convertito questa data in tick e poi la ho passata a java come long.

frammento di codice:

preso:

- long TICKS_AT_EPOCH = 621355968000000000L; 
- long TICKS_PER_MILLISECOND = 10000; 

java.util.Date date = new java.util.Date((ctime - TICKS_AT_EPOCH)/TICKS_PER_MILLISECOND); 

Ora java data util è Sab 8 giugno 06:02:07 CDT 2013

Si noti che l'ora è differenza di 5 ore.

Qualche suggerimento perché?

+0

Sono ancora confuso. Ho letto la data dal database SQL (il server è in Ora centrale) nell'applicazione C# e la assegna all'oggetto Date # C#. Visualizza la data e l'ora corrette nell'applicazione C# ma non sono sicuro su quale fuso orario è impostato su DateTime. Come lo scopro? –

+0

Questo è ciò che mostra l'applicazione C# per la data: Jun Sat 8 11:02 2013 -05: 00 –

risposta

0

Il ctime è UTC (tempo coordinato universale), che è uno standard temporale riferito a Greenwich. Stai esprimendo il tuo tempo in ora centrale. C'è la tua differenza.

1

Il tempo non è di 5 ore indietro, è esattamente la stessa ora. Il problema è nel modo in cui lo stampi.

È necessario indicare a C# ea Java di utilizzare lo stesso fuso orario durante la conversione della data in stringa. Uno di questi utilizza UTC e l'altro CDT.

5

Si sta costruendo un java.util.Date basato su millisecondi dal 1/1/1970 UTC. Sembra che si stia correggendo dal fatto che i file .net System.DateTime.Ticks sono basati su 1/1/0001 e sono 10.000 tick al millisecondo. È corretto, ma hai dimenticato di adattarti a UTC.

In .Net, il valore proveniente da DateTime.Ticks dipende fortemente dalla proprietà DateTime.Kind. Esistono tre possibili tipi di valori DateTime.

  • DateTimeKind.Utc - Questo genere significa che il valore rappresenta il tempo UTC. Di solito proviene da una chiamata a DateTime.UtcNow, ma può anche essere costruita direttamente, e spesso lo è. Ad esempio, potresti recuperare le ore UTC da un database. Puoi alimentare i tick da qui direttamente nella tua conversione, e funzionerà.

  • DateTimeKind.Local - Questo di solito viene da una chiamata a DateTime.Now. I valori sono rappresentativi del fuso orario locale. Dovrai convertire in UTC prima di controllare i tick. È possibile effettuare le seguenti operazioni:

    DateTime dt = DateTime.Now; 
    int utcTicks = dt.ToUniversalTime().Ticks; 
    

    essere consapevoli che se il tempo si verifica nel corso di un legale "di ripiego" transizione stile, il risultato potrebbe non essere corretto. La classe DateTime non ha idea dei fusi orari. Riflette solo l'attuale orologio locale. Se il valore in dt è ambiguo, ToUniversalTime() assumerà che il valore sia rappresentativo di tempo standard, anche se lo si è appena recuperato mentre in ora legale. Questo è solo uno dei molti aspetti confusi e probabilmatici di DateTime in .net.

  • DateTimeKind.Unspecified - Questo è il tipo più comune di DateTime si incontrano, e di solito proviene da DateTime.Parse() o un costruttore come new DateTime(...). Sfortunatamente, non c'è niente qui che ti indicherà il fuso orario in cui queste date sono rappresentative. Puoi comunque provare a chiamare .ToUniversalTime(), ma il framework supporrà che questi orari siano rappresentativi del fuso orario locale, come se il tipo fosse Local. Questa ipotesi potrebbe essere completamente sbagliata, a seconda del modo in cui hai fornito i dati. Non esiste un modo sicuro per trasformare un valoreDateTime in un valore UTC (segni di spunta o altro).

ci sono alcune soluzioni, come l'uso DateTimeOffset invece di DateTime, o utilizzando la libreria al posto dei tipi built-in Noda Time. Puoi leggere di più su questi problemi here e here.

Problemi correlati