TimeZone issue in 1.8u60

[Naoto Sato]

Yes. They are specified in the javadoc for 
DateFormatSymbols.getZoneStrings().

http://docs.oracle.com/javase/8/docs/api/java/text/DateFormatSymbols.html#getZoneStrings--

Naoto

On 6/14/15 3:32 PM, Tomasz Kowalczewski wrote:
> Thank you for this explanation. Do I understand correctly that first
> five elements of this seven element array are the same as five element
> array in Java versions before 1.8u60?
>
> On Wed, Jun 10, 2015 at 11:45 PM, Naoto Sato <naoto.sato at oracle.com
> <mailto:naoto.sato at oracle.com>> wrote:
>
>     Hi Tomasz,
>
>     The change was made to fix a performance regression in JDK8:
>
>     https://bugs.openjdk.java.net/browse/JDK-8076287
>
>     Those time zone names weren't cached in JDK8, so the fix was to
>     cache those arrays, which are also shared with
>     ZoneId.getDisplayName() which can also return generic names.
>
>     HTH,
>     Naoto
>
>
>     On 6/10/15 4:21 AM, Tomasz Kowalczewski wrote:
>
>         Hi,
>
>         I am not sure where to write about this, I hope somebody will
>         point me to
>         right list if this one is not correct.
>
>         I have been playing with newest Java 1.8u60 to try
>         PreserveFramePointer
>         functionality. Unfortunately none of our servers start on this
>         version of
>         java. It is because of REST call to Amazon services done during
>         startup.
>         None of these calls worked.  Unless I am missing something it
>         turns out to
>         be issue with formatting time zone information as done by Joda
>         Time. It
>         uses calls to:
>
>         DateTimeUtils.getDateFormatSymbols(Locale.ENGLISH).getZoneStrings();
>
>         to get list of timezones. This usually returned array of arrays of 5
>         elements. In 1.8u60 it returns array of arrays of 7 elements.
>
>         I know that all this software is not related to OpenJDK and calling
>         getZoneStrings is discouraged in the docs. But as I am
>         unfamiliar with time
>         zones mechanisms inside JDK (loading from bundles etc.) I was
>         hoping that
>         somebody will point me to change that may caused this for sake
>         of better
>         understanding the issue.
>
>
>
>
> --
> Tomasz Kowalczewski