mexico - timezone java

¿Por qué se agrega una hora a java.util.Date para fechas anteriores al 1 de noviembre de 1971?

Question

El siguiente código parece demostrar un error en java.util.Fecha en la que se agrega una hora si el reloj local está configurado a GMT con el ajuste de horario de verano activado y la hora es antes del 1 de noviembre de 1971. Mi primer supuesto es siempre que Entendiste mal. ¿Alguien puede ver lo que está mal (o esto es realmente un error de Java)? ¿Qué tiene de importante el 1 de noviembre de 1971?

import java.text.SimpleDateFormat;
import java.util.Locale;
import java.util.TimeZone;
class JavaUtilDateBug
{
private static void demo() throws Exception
{
// UK developers usually have the clock on their development machines set
// to "Europe/London" (i.e. GMT with daylight saving). Set it explicitly
// here so readers in other countries can see the problem too.
TimeZone.setDefault(TimeZone.getTimeZone("Europe/London"));
Locale.setDefault(Locale.ENGLISH);
SimpleDateFormat dateFormat = new SimpleDateFormat("EEE MMM dd HH:mm:ss z yyyy");
String strJan1st1970Expected = "Thu Jan 01 00:00:00 GMT 1970";
String strJan1st1970Actual = dateFormat.parse(strJan1st1970Expected).toString();
System.out.println("strJan1st1970Actual: " + strJan1st1970Actual); // -> "Thu Jan 01 01:00:00 GMT 1970"
boolean jvmHasDateBug = !strJan1st1970Expected.equals(strJan1st1970Actual);
System.out.println("jvmHasDateBug: " + jvmHasDateBug); // -> true
// The anomaly only seems to affect times before 1 Nov 1971.
final String strNov1st1971 = "Mon Nov 01 00:00:00 GMT 1971";
assert strNov1st1971.equals(dateFormat.parse(strNov1st1971).toString());
}
public static void main(String[] args)
{
try
{
demo();
}
catch (Exception e)
{
e.printStackTrace();
}
}
}

Mi entorno Java:

 java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)

Answer 1

Encontré un error coincidente en la base de datos de errores de Sun. Parece que lo consideran una "inexactitud histórica" ​​(el formato aparentemente debería producir "BST" como zona horaria en lugar de GMT, entonces la hora sería correcta) y no lo solucionará, porque en el fondo, la implementación de TimeZone no puede manejar lugares cambiando el nombre de su zona horaria.

Como solución alternativa, puede establecer explícitamente su zona horaria en GMT en lugar de "Europa / Londres". El problema entonces desaparece.

Answer 2

Es el local De http://en.wikipedia.org/wiki/British_Summer_Time

el esquema de hora estándar británica se probó entre el 27 de octubre de 1968 y el 31 de octubre de 1971, cuando Gran Bretaña permaneció en GMT + 1 todo el año.

Answer 3

Esto no es un error.

Ha establecido su zona horaria predeterminada en BST que es (GMT + 1) , la fecha GMT del Jan 1 1970 00:00:00 de Jan 1 1970 00:00:00 , cuando analiza esta fecha utilizando la zona horaria BST como su valor predeterminado, siempre muestra la hora según su zona horaria actual (auto aplica el offset de GMT ).

En este caso, fue GMT + 1 lo que su resultado fue de una hora libre.

Answer 4

Hubo un ensayo de la hora estándar británica entre el 27 de octubre de 1968 y el 31 de octubre de 1971, que sospecho que es lo que está causando este problema.

Aquí hay algunos detalles del juicio:

http://en.wikipedia.org/wiki/British_Summer_Time#Single.2FDouble_Summer_Time

La zona horaria para Europa / Londres en el 1 de enero de 1970 fue la hora estándar británica (GMT + 1), por lo que cuando utiliza un java.text.SimpleDateFormat para analizar 01 de enero a las 00:00:00 GMT de 1970, genera el valor de época correcto igual al 1 de enero. 01:00:00 1970 en BST.

Luego, debido a la mierda de java.util.Date , cuando llamas a java.util.Date.toString() usa la zona horaria predeterminada para el local actual a partir de ahora , que ha cambiado a GMT y obtienes el 1 de enero 01: 00:00 GMT 1970.