¿Un 'z' en una fecha y hora de cuerdas tiene diferentes salidas en diferentes lugares?

deHaar:

No hace mucho tiempo, he proporcionado una respuesta a una pregunta acerca de cómo extraer la zona horaria de un ZonedDateTimeanalizada desde una String.
Se trabajó en general, pero había diferentes salidas del mismo código en el sistema de OP mi un uno, lo que de alguna manera no me deja ir nunca más.

La pregunta relacionada preguntó cómo conseguir un ZoneIdde una ZonedDateTimey me proporcionó una manera. Es cierto que no es la respuesta aceptada, pero aún valía la pena un upvote de alguien.

Lo especial de mi respuesta es preocupante el 'z'en el patrón utilizado para analizar el tiempo String. Hay un nombre de zona horaria en la que se Stringrepresenta la zona "Australia/Adelaide"por "... ACST"(Australia Central Standard Time).

Cuando analizo en mi sistema de impresión y / formatear el ZonedDateTimeuso de la DateTimeFormatter.ISO_ZONED_DATE_TIME, imprime el tiempo en "America/Manaus"y después de haber extraído el ZoneId, todavía es que uno de América del Sur. OP declaró en un comentario a mi respuesta, que en su sistema, al menos uno de los espectáculos líneas de salida deseada del / correcta ZoneId.

¿Cómo es eso posible? ¿El defecto del sistema de localización tienen ninguna influencia en el análisis 'z'de fecha y hora Strings?

Este es el código de mi respuesta en la pregunta además una salida de mi ZoneId.systemDefault():

public static void main(String args[]) throws Exception {
    String time = "2 Jun 2019 03:51:17 PM ACST";
    String pattern = "d MMM yyyy hh:mm:ss a z"; // z detects the time zone (ACST here)
    DateTimeFormatter formatter = DateTimeFormatter.ofPattern(pattern);

    // parse a time object using the formatter and the time String
    ZonedDateTime zdt = ZonedDateTime.parse(time, formatter);
    // print it using a standard formatter
    System.out.println(zdt.format(DateTimeFormatter.ISO_ZONED_DATE_TIME));
    // extract the zone id
    ZoneId zoneId = zdt.getZone();
    ZoneId sysDefault = ZoneId.systemDefault();
    // print the zone id
    System.out.println("Time zone of parsed String is " + zoneId);
    System.out.println("System default time zone is " + sysDefault);

    // retrieve the instant seconds
    Instant instant = zdt.toInstant();
    // print the epoch seconds of another time zone
    System.out.println("Epoch seconds in Australia/Adelaide are " 
            + instant.atZone(ZoneId.of("Australia/Adelaide")).toEpochSecond());
}

y su salida es la siguiente:

2019-06-02T15:51:17-04:00[America/Manaus]
Time zone of parsed String is America/Manaus
System default time zone is Europe/Berlin
Epoch seconds in Australia/Adelaide are 1559505077

¿Puede mi punto de una persona a un error que he hecho o confirmar y explicar la influencia de diferentes defecto del sistema ZoneIds de analizar una Stringa una ZonedDateTime?

VV Ole:

Yo también he tenido abreviaturas de zona horaria ambigua que se analizan de manera diferente en diferentes máquinas virtuales de Java (también en la prestación de un local, por lo que no es el único problema). No creo que el comportamiento exacto está documentado. En algunos casos se eligió la zona horaria predeterminada JVM, no sé si será siempre cuando coincide, sin embargo.

Se puede controlar la elección de zona horaria en casos ambiguos a través de la sobrecargado DateTimeFormatterBuilder.appendZoneText(TextStyle, Set<ZoneId>)método.

Un ejemplo en el local hace una diferencia: Europe / Berlin y muchas otras zonas horarias europeas será formateado en Central European Timeo CETen muchos lugares. En una configuración regional alemana en su lugar se convierten en Mitteleuropäische Zeito MET.