2012-07-03 15 views
10

Al ejecutar algunas pruebas me encontré con el siguiente problema. En el uso:Usando DateFormat.getDateTimeInstance(). Format (date);

private String printStandardDate(Date date) { 
    return DateFormat.getDateTimeInstance(
     DateFormat.SHORT, DateFormat.SHORT).format(date); 
} 

me encontré con esto produjo diferentes formatos de fecha, dependiendo de la ubicación de las pruebas en las que huir. Así que localmente en Windows/Eclipse obtuve un resultado: 04/02/12 18:18 pero en la caja de Linux en Estados Unidos me sale 2/4/12 6:18 PM

Esto hace que mis Tests/Build fallen:

esperada: < [04/02/12 18:18]> pero era: < [2/4/12 18:18]>

Podría alguien explicar este comportamiento?

+0

usted no dio la zona horaria en cada servidor –

+0

En este momento estoy en la zona horaria GMT y la caja de Linux es EST – Mick

+0

Edwin Dalorzo darle buen ejemplo –

Respuesta

14

Eso no es extraño, así es exactamente como debería funcionar.

La documentación de la API de DateFormat.getDateTimeInstance dice:

Obtiene el formateador de fecha/hora con la fecha y hora determinada estilos de formato para la configuración regional predeterminada.

La configuración regional predeterminada es diferente en su sistema Windows que en la máquina Linux en América.

Si desea un control exacto sobre el formato de fecha y hora, utilice SimpleDateFormat y especifique el formato usted mismo. Por ejemplo:

private String printStandardDate(Date date) { 
    return new SimpleDateFormat("dd/MM/yy HH:mm").format(date); 
} 

Aún mejor sería volver a utilizar el objeto SimpleDateFormat, pero ten cuidado de que no es hilo de seguridad (si el método puede ser llamado desde varios subprocesos al mismo tiempo, las cosas van a llegar en mal estado arriba si esos hilos usan el mismo objeto SimpleDateFormat).

private static final DateFormat DATE_FORMAT = 
    new SimpleDateFormat("dd/MM/yy HH:mm"); 

private String printStandardDate(Date date) { 
    return DATE_FORMAT.format(date); 
} 
7

El formato se basa en la configuración regional predeterminada de su código. Si desea garantizar los resultados, debe asegurarse de usar una configuración regional específica. El método getDateTimeInstance está sobrecargado para ofrecer un alternative method que recibe la configuración regional que desea usar como parámetro.

public static final DateFormat getDateTimeInstance(int dateStyle, 
          int timeStyle, 
          Locale aLocale) 

Si usa la misma configuración regional en ambos entornos de prueba, el resultado debería ser el mismo.

+0

en realidad no deberían, ya que 'TimeZone.getDefault()' también cumple una función, por lo que también debe establecerse. Esta es una buena respuesta, no obstante. – eis