zona obtener mexico horaria java javascript date timezone primefaces-extensions

mexico - obtener zona horaria java



¿Por qué la fecha está cambiando con el mismo número de milisegundos en diferentes zonas horarias? (3)

Sabemos que el método getTime de java.util.Date devuelve el número de milisegundos desde el 1 de enero de 1970, 00:00:00 GMT representado por este objeto Date.

Noté una situación extraña como la siguiente;

La zona horaria del sistema es: (UTC + 02: 00) Estambul

Date currentDate = new Date(); System.out.println(currentDate .getTime()); System.out.println(currentDate);

Java ConsoleOutput:

1360753217219

Mié 13 feb 13:00:17 VET 2013

Entonces mi plugin de javascript está usando este objeto largo como el siguiente;

Javascript:

console.log(new Date(1360753217219));

Browser ConsoleOutput:

Fecha {Mié 13 de febrero 2013 13:00:17 GMT + 0200 (Hora estándar de Turquía)}

¡Eso está todo bien, sin embargo! Después de cambiar mi zona horaria local como (UTC-04: 30) Caracas, la situación y la hora cambian de la siguiente manera con el mismo número de milisegundos;

Javascript:

console.log(new Date(1360753217219));

Browser ConsoleOutput:

Fecha {Mié 13 de febrero 2013 06:30:17 GMT-0430 (Hora estándar de Venezuela)}

¿Alguien puede explicar esto? ¿Es ese js error? O más importante aún, ¿cómo debo manejar esto en el lado de Java, para obtener la misma fecha con el mismo número de milisegundos para diferentes zonas horarias en el lado js?

¡Gracias!

tl; dr

Instant.ofEpochMilli( 1_360_753_217_219L ) // UTC

2013-02-13T11: 00: 17.219Z

Instant.ofEpochMilli( 1_360_753_217_219L ) .atZone( ZoneId.of( "Europe/Istanbul" ) ) // Same moment, two hours *ahead* of UTC.

2013-02-13T13: 00: 17.219 + 02: 00 [Europa / Estambul]

Instant.ofEpochMilli( 1_360_753_217_219L ) .atZone( ZoneId.of( "America/Caracas" ) ) // Same moment, four-and-a-half hours *behind* UTC.

2013-02-13T06: 30: 17.219-04: 30 [América / Caracas]

Usando java.time

Está utilizando antiguas clases problemáticas de fecha y hora incluidas con las primeras versiones de Java. Ahora son heredados, suplantados por las clases java.time, la mejor biblioteca de fecha y hora en cualquier plataforma.

Comience con su número de milisegundos desde una fecha de referencia de época de principios de 1970 en UTC (1970-01-01T00: 00: 00Z). Otros señalan que no puede comprender que una fecha de referencia de época tiene un huso horario, y aquí con esta época esa zona es UTC, un desplazamiento de cero horas. Todos los demás desplazamientos se miden con respecto a este, un número de horas y minutos por delante de UTC o detrás de UTC.

La clase Instant representa un momento en la línea de tiempo en UTC con una resolución de nanosegundos (hasta nueve (9) dígitos de una fracción decimal).

long input = 1_360_753_217_219L ; Instant instant = Instant.ofEpochMilli( input ) ;

instant.toString (): 2013-02-13T11: 00: 17.219Z

Si desea ver ese mismo momento a través de la lente del reloj de pared de una región en particular, aplique una zona horaria.

Una zona horaria es un historial de cambios pasados, presentes y futuros a la compensación en uso por una región en particular.

Especifique un nombre de zona horaria adecuada en el formato continent/region , como America/Montreal , Africa/Casablanca o Pacific/Auckland . Nunca utilice la abreviatura de 3-4 letras, como EST o IST ya que no son zonas horarias verdaderas, no están estandarizadas y ni siquiera son únicas (!).

ZoneId zEurope_Istanbul = ZoneId.of( "Europe/Istanbul" ) ; ZonedDateTime zdtEurope_Istanbul = instant.atZone( zEurope_Istanbul ) ;

zdtEurope_Istanbul.toString (): 2013-02-13T13: 00: 17.219 + 02: 00 [Europa / Estambul]

Puede aplicar otra zona horaria.

ZoneId zAmerica_Caracas = ZoneId.of( "America/Caracas" ) ; ZonedDateTime zdtAmerica_Caracas = zdtEurope_Istanbul.withZoneSameInstant( zAmerica_Caracas ) ;

zdtAmerica_Caracas.toString (): 2013-02-13T06: 30: 17.219-04: 30 [América / Caracas]

Vea este código en vivo en IdeOne.com .

Estos tres objetos, instant & zdtEurope_Istanbul & zdtAmerica_Caracas, representan el mismo momento simultáneo , el mismo punto en la línea de tiempo.

Su recuento de la época representa las 11 a.m. en hora UTC. Estambul está dos horas adelante de UTC, por lo que la hora del día en el mismo momento es dos horas después de las 11 AM, 1 PM (13:00). Venezuela está a cuatro horas y media de UTC, por lo que la hora del día en el mismo momento es a las 6:30 a.m. Todo esto tiene sentido, en el mismo momento, pero diferente tiempo de reloj de pared.

ISO 8601

No utilice una cuenta de época para intercambiar o almacenar valores de fecha y hora. Eso es propenso a errores, es impracticable para leer de manera significativa por un ser humano, y ambiguo ya que hay al menos un par de docenas de fechas de referencia de época en uso por varios sistemas de software y en diferentes granularidades (segundos enteros, milisegundos, microsegundos, nanosegundos, etc. )

Al pasar valores de fecha y hora fuera de su JVM, use los formatos estándar ISO 8601 para la representación textual. Las clases java.time utilizan los formatos estándar de forma predeterminada al analizar / generar cadenas. Puede ver esos formatos en el código de ejemplo de esta Respuesta.

Acerca de java.time

El marco java.time está integrado en Java 8 y posterior. Estas clases suplantan a las problemáticas antiguas clases heredadas de fecha y hora, como java.util.Date , Calendar y SimpleDateFormat .

El proyecto Joda-Time , ahora en modo de mantenimiento , aconseja la migración a las clases java.time .

Para obtener más información, consulte el Tutorial de Oracle . Y busque para obtener muchos ejemplos y explicaciones. La especificación es JSR 310 .

¿Dónde obtener las clases de java.time?

El proyecto ThreeTen-Extra amplía java.time con clases adicionales. Este proyecto es un terreno de prueba para posibles adiciones futuras a java.time. Puede encontrar algunas clases útiles aquí, como Interval , YearWeek , YearQuarter y más .

Los milisegundos son agnósticos de zona horaria. El tiempo se mide como absoluto desde el 1 de enero de 1970 GMT. Entonces, la idea es que obtienes los milisegundos y luego resuelves cuál es la hora local para un huso horario determinado después del hecho. Si lo piensas, tiene sentido. La cantidad de milisegundos transcurridos desde 1970 es la misma sin importar dónde se encuentre.

Se pone un poco confuso, pero NO fideos con los milisegundos para ajustar las zonas horarias. Cada biblioteca de Date tiene mecanismos para traducir un sello de milisegundos en un horario local específico de zona horaria.

Entonces, si su pregunta específica es cómo comunicar la fecha de manera efectiva entre el servidor y el cliente (los idiomas que está utilizando no son importantes), la respuesta es que es perfectamente seguro pasar milisegundos de un lado a otro y resolver en ambos lados lo que hora específica de la que está hablando, si eso es importante para el contexto de lo que está haciendo en ese momento.

no es un error, así es como funcionan las zonas horarias.

Si llama a alguien en Venezuela ahora mismo y le pregunta qué hora es, le dirá que es 6.5 (según su ejemplo) horas antes que el horario en Turquía.

como mencionaste, el número con el que estás tratando representa el número de milisegundos desde 1970, 00:00:00 GMT , en Caracas en ese mismo segundo, era el 31.12.1969 19:30 GMT-0430

entonces, sin embargo, muchos segundos después, el tiempo en Venezuela todavía será 4:30 horas antes en comparación con GMT.

no puede obtener la misma fecha exacta en diferentes zonas horarias si usa la misma entrada (milisegundos) porque eso simplemente sería incorrecto.

si desea obtener el mismo resultado, puede agregar la diferencia en zonas horarias (6.5 horas en este caso) a la salida. siguiendo el consejo del Dr. Dredel, probablemente no deberías meterse con los milisegundos.