zona studio obtener horaria hora formato actual java timezone iso8601 timezoneoffset

java - studio - Identificación de zonas horarias en ISO 8601



obtener hora actual java (2)

Entiendo que estos no son compatibles con ISO 8601, ¿correcto?

Correcto. ISO-8601 no se preocupa por los identificadores de zona horaria. Los nombres IANA / Olson TZ no son un "estándar". Son lo más confiable que tenemos. (Algunos pueden considerarlos el estándar de facto ).

¿Qué están haciendo las plataformas para apoyar esto?

Apoye lo que exactamente? Esta parte de tu pregunta no está clara. Si quieres apoyar las zonas horarias de IANA, bueno, eso está por todos lados. Algunas plataformas las tienen incorporadas, y otras dependen de las bibliotecas. Si desea admitir una representación de cadena de un identificador ISO-8601 fecha-hora-offset + zona horaria, algunas plataformas tienen esto y otras no. Tendrás que ser más específico si quieres saber más.

Observé que la última biblioteca de fecha / hora de Java usa un formato extendido ISO 8601 para esto, por ejemplo, 2011-12-03T10: 15: 30 + 01: 00 [Europa / París]. (Consulte la API DateTimeFormatter).

Creo que estás hablando de DateTimeFormatter.ISO_ZONED_DATE_TIME . Los documentos dicen específicamente:

El formateador de fecha y hora similar a ISO ...

... amplía el formato de fecha y hora de compensación extendida ISO-8601 para agregar la zona horaria. La sección entre corchetes no es parte del estándar ISO-8601.

Entonces este es el formato específico de Java, no un estándar.

¿Hay alguna convención convergente (por ejemplo, con otros lenguajes y plataformas) para extender ISO 8601 para admitir la designación de zona horaria?

Hasta donde sé, actualmente no existe un estándar que cubra la combinación de una marca de tiempo ISO8601 y un identificador de zona horaria IANA en un formato único. Uno podría representarlo de muchas maneras diferentes, incluyendo:

  • 2011-12-03T10:15:30+01:00[Europe/Paris] (este es el valor predeterminado en Java 8)
  • 2011-12-03T10:15:30+01:00(Europe/Paris)
  • 2011-12-03T10:15:30+01:00 Europe/Paris
  • 2011-12-03T10:15:30+01:00 - Europe/Paris
  • 2011-12-03T10:15:30+01:00/Europe/Paris
  • 2011-12-03T10:15:30+01:00|Europe/Paris
  • 2011-12-03T10:15:30 Europe/Paris (+01) (este es el valor predeterminado en Noda Time)

Si lo que está buscando es una forma de incluir un ZonedDateTime o datos similares en una API de manera estandarizada, mi recomendación personal sería pasar el nombre de la zona horaria en un campo separado. De esta forma, cada porción de datos es tan buena como puede ser. Por ejemplo en JSON:

{ "timestamp": "2011-12-03T10:15:30+01:00", "timezone": "Europe/Paris" }

No, no estoy hablando de compensaciones de zona, que pueden variar durante el año para una región basada, por ejemplo, en el horario de verano. Estoy hablando de las zonas horarias reales mantenidas por IANA . Entiendo que estos no son compatibles con ISO 8601, ¿correcto?

¿Qué están haciendo las plataformas para admitir la identificación de zonas horarias en representaciones de cadenas similares a ISO 8601? Observé que la última biblioteca de fecha / hora de Java usa un formato extendido ISO 8601 para esto, por ejemplo, 2011-12-03T10:15:30+01:00[Europe/Paris] . (Consulte la API DateTimeFormatter ).

¿Hay alguna convención convergente (por ejemplo, con otros lenguajes y plataformas) para extender ISO 8601 para admitir la designación de zona horaria?

La respuesta de Matt Johnson es correcta. Solo agregaré algunos pensamientos.

Zona horaria versus desplazamiento desde UTC

Un desplazamiento desde UTC es simplemente un número de horas, minutos y segundos por delante / detrás de UTC . Solo, esto hace que una fecha sea un momento específico en la línea de tiempo. Pero tampoco es tan informativo como incluir el nombre de la zona horaria oficial .

Si bien aún no existe un estándar para incluir el nombre de la zona horaria, espero que otros sigan el ejemplo de las clases de java.time al agregar entre corchetes el nombre de la zona horaria. Este formato me parece sensato, ya que sería simple truncar la parte del paréntesis cuadrado para que sea compatible con versiones anteriores con software no inteligente.

Por ejemplo:
2011-12-03T10:15:30+01:00[Europe/Paris] . Si los datos fueran solo 2011-12-03T10:15:30+01:00 , podríamos identificar el momento en la línea de tiempo, pero no seríamos capaces de ajustar otros momentos en el mismo estado de ánimo ya que no lo haríamos saber qué reglas de ajuste aplicar. Zonas como Europe/Zagreb , Africa/Brazzaville , Arctic/Longyearbyen y Europe/Isle_of_Man comparten el desplazamiento de +01:00 , pero es posible que tengan otros ajustes en vigor que difieran de los de Europe/Paris . Por lo tanto, si intentara agregar tres días al valor 2011-12-03T10:15:30+01:00 , realmente no puede calcular fielmente el resultado porque no sabe qué ajustes se deben aplicar, como los cambios de horario de verano que puede estar ocurriendo durante esos tres días.

Una zona horaria define el conjunto de reglas para manejar anomalías como el horario de verano (DST) . Los políticos de todo el mundo disfrutan haciendo ajustes en sus husos horarios, o incluso redefiniéndolos. Entonces estas reglas cambian frecuentemente. Piense en una zona horaria como una colección de compensaciones a lo largo del tiempo, muchos períodos de tiempo en la historia en los que cada período tenía una compensación particular en uso en esa región en particular.

Puede pensar en una zona horaria como una colección de valores de compensación de UTC. En America/Los_Angeles parte de este año tiene 8 horas de retraso con respecto a UTC, y parte del año estará 7 horas por detrás de UTC. Eso hace que se recopilen 2 puntos de datos como parte de esa zona horaria.

Otro ejemplo, en años anteriores, Turquía pasó parte de cada año 2 horas antes de UTC y parte de cada año 3 horas más adelante. En 2016, eso cambió a permanecer indefinidamente 3 horas más adelante. Entonces, múltiples puntos de datos en la zona horaria Europe/Istanbul .

Solo usa UTC

Personalmente, no veo mucho valor incluso en el uso de valores tales como 2011-12-03T10:15:30+01:00 . Sin un huso horario, también podría usar UTC solo. En este caso, 2011-12-03T09:15:30Z (9 AM en lugar de 10 AM).

Generalmente, la mejor práctica es usar UTC al almacenar e intercambiar valores de fecha y hora. Piense en UTC como One-True-Time , con valores zonificados o desplazados que son meras variaciones.