2011-07-26 25 views
11

¿Por qué falla esta prueba:JodaTime y retorno Calendario diferentes resultados

DateTime dateTime = new DateTime(1997,01,01,00,00,00,00, DateTimeZone.UTC); 
    long jodaMills = dateTime.getMillis(); 

    Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("UTC")); 
    cal.set(1997,01,01,00,00,00); 
    long calMills = cal.getTimeInMillis(); 

    Assert.assertEquals(jodaMills, calMills); 

consigo un resultado de: esperado: 852076800000 real: 854755200964

¿No deberían ser el mismo número ?

+0

¿Hay alguna razón por la que utilice números octales? – soc

Respuesta

13

dos razones:

  1. Joda tiene un mes de base. Entonces necesitas cambiar eso.

  2. El calendario está mal diseñado. No necesita configurar los milisegundos de la segunda a 0. cal.set(MILLISECOND, 0)

Aquí está el javadoc años

pública final conjunto vacío (int, int mes, fecha int, int hourOfDay, int minutos, int segundos)

que le falta el campo milisegundo.

+0

Esta es también la razón por la que los milisegundos no coinciden con –

+0

do'h! Yo también lo sabía ... siempre me atrapa. – ryber

20

Calendario tiene cero meses, con base y JodaTime campos meses comienza a 1.

Así, en JodaTime, enero es el mes 1, pero en Calendario, enero es el mes 0.

Por lo tanto, en su ejemplo está comparando 1 de enero a 1 de febrero, de ahí la diferencia de valores.

También hay una diferencia en milisegundos, ya que JodaTime se establece en cero, pero el objeto de calendario no lo está.

3

Voy a adivinar aquí que 1997, 01,01 para Joda significa 1 de enero de 1997.

Pero en Java Calendar, los meses están numerados del 0 al 11, entonces 1997,01,01 para Java es en realidad el 1 de febrero.

Un mejor enfoque es utilizar -

cal.set(1997, Calendar.JANUARY, 01, 00,00,00); 

También debe restablecer los milisegundos del objeto Calendar a 0 como @Amir señaló.

4

anotaciones frente a una base cero basados ​​en

+2

+1, me gustan los tiradores directos. – Moonbeam

Cuestiones relacionadas