That means the US locale cannot understand CET as timezone then?
And... it assuming that TimeZone.getTimeZone('Etc/GMT') returns the GMT
timezone, it means the short format for a date changed from using 70 for
the year to 1970? Or is that CLDR related as well?
bye blackdrag
Am 09.07.2015 21:27, schrieb Naoto Sato:
I meant the root cause seems to be the same between your first issue and
8130845, where parsing short time zone names has some problem regardless
of it's the ROOT locale or not.
Naoto
On 7/9/15 12:23 PM, Jochen Theodorou wrote:
but both examples set a locale I thought
Am 09.07.2015 21:06, schrieb Naoto Sato:
Hi Jochen,
It is likely that these are caused by the default locale data change to
CLDR with 8008577.
On 7/9/15 10:12 AM, Jochen Theodorou wrote:
Hi,
after fixing some JDK9 related bugs in our build for Groovy we stumbled
over
new SimpleDateFormat("EEE MMM dd HH:mm:ss zzz yyyy",
Locale.US).parse("Thu Jan 01 01:00:00 CET 1970")
failing to parse with
java.text.ParseException: Unparseable date: "Thu Jan 01 01:00:00 CET
1970"
at java.text.DateFormat.parse(DateFormat.java:366)
This happens not with my local machine using jdk1.9.0-ea-b68, but it
does fail on our CI server used revision 0906b79c9df4 for this.
This seems to be the same issue which has already been reported in
8130845.
A second case is this one:
Locale locale = Locale.UK
Locale.setDefault locale
TimeZone.setDefault TimeZone.getTimeZone('Etc/GMT')
Date d = new Date(0)
assertEquals '01/01/70',
DateFormat.getDateInstance(DateFormat.SHORT).format(d);
the assert used to work, but now the format changed to print 01/01/1970
instead of 01/01/70. With the same constellation regarding jdk
versions.
This is expected, as the short date format for UK in CLDR is "dd/MM/y".
Naoto
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
