Hello Rory & Muneer,
Is the change UCT -> UTC time zone have been backported to Java 11 ? Or it
is only in Java 13 ?
We just tried GitHub Actions and the test has failed on their Java 11.0.4
installation: https://github.com/apache/wicket/runs/196487121
Me and another Wicket developer tested with 11.0.4 on our Ubuntu machines
(installed with "apt install openjdk-11-jdk") but the test passed locally.
I have the feeling that GitHub's installation of Java 11 is corrupted
somehow but it could also be the Ubuntu package that we have.
Kind regards,
Martin
On Tue, Jul 23, 2019 at 4:05 AM <abdul.kolarku...@oracle.com> wrote:
> Yea Martin, don't need a ticket for this.
>
> It's an expected behavior from build 30 onwards.
>
> -Muneer
>
> On 22/07/19 6:16 PM, Martin Grigorov wrote:
>
> Hi Muneer,
>
> Yes, this ticket explains the problem:
>
> Etc/UCT is now a backward-compatibility link to Etc/UTC, instead
> of being a separate zone that generates the abbreviation "UCT",
> which nowadays is typically a typo. (Problem reported by Isiah
> Meadows.)
>
> So it seems there is no need of a ticket.
>
> Otherwise the reproducer is :import java.time.ZonedDateTime;
> import java.time.format.DateTimeFormatter;
> import java.time.format.FormatStyle;
> import java.time.temporal.TemporalAccessor;
> import java.util.Locale;
>
> public class Java13Build30
> {
> public static void main(String[] args)
> {
> String toParse = "Jul 11, 2016, 1:02:03 AM Coordinated Universal
> Time";
> Locale locale = Locale.ENGLISH;
> DateTimeFormatter dateTimeFormatter =
> DateTimeFormatter.ofLocalizedDateTime(FormatStyle.MEDIUM,
> FormatStyle.FULL).withLocale(locale);
> final TemporalAccessor temporalAccessor =
> dateTimeFormatter.parse(toParse);
> final ZonedDateTime zonedDateTime =
> ZonedDateTime.from(temporalAccessor);
> System.err.println(zonedDateTime);
> }
> }
>
> Regards,
> Martin
>
> On Mon, Jul 22, 2019 at 3:40 PM <abdul.kolarku...@oracle.com> wrote:
>
>> Hi Martin,
>>
>> This enhancement task description may help you:
>> https://bugs.openjdk.java.net/browse/JDK-8224560
>> .
>> <https://bugs.openjdk.java.net/browse/JDK-8224560>
>>
>> It is included in JDK 13 build 30.
>>
>> -Muneer
>>
>> On 22/07/19 6:00 PM, Rory O'Donnell wrote:
>>
>> Hi Martin,
>>
>> A reproducer would be great.
>>
>> Thanks,Rory
>> On 22/07/2019 13:03, Martin Grigorov wrote:
>>
>> Hi,
>>
>> I won't have time now to extract a mini reproducer but if anyone else has
>> time here are some details:
>>
>> the test tries to parse "Jul 11, 2016, 1:02:03 AM Coordinated Universal
>> Time" with Locale.ENGLISH
>> In earlier versions of Java it returns a ZonedDateTime.of(2016, 7, 11, 1,
>> 2, 3, 0, ZoneId.of("Etc/UCT"))
>> with Java 13 b30 the zone id is "Etc/UTC"
>> I am not sure what UCT is and whether it is a valid zone, but it seems to
>> be a valid one.
>>
>> On Mon, Jul 22, 2019 at 2:48 PM Martin Grigorov <mgrigo...@apache.org>
>> wrote:
>>
>>> Hi Rory,
>>>
>>> There is a test failure with Java 13 build 30 in Apache Wicket:
>>>
>>> INFO] Results:
>>> [INFO]
>>> [ERROR] Failures:
>>> [ERROR] ZonedDateTimeConverterTest.convertToObject:46 expected:
>>> <2016-07-11T01:02:03Z[Etc/UTC]> but was: <2016-07-11T01:02:03Z[Etc/UCT]>
>>>
>>> Java 13 returns UCT instead of UTC as a ZoneId.
>>> Is this expected ?
>>>
>>> Regards,
>>> Martin
>>>
>>>
>>> On Mon, Jul 22, 2019 at 1:18 PM Rory O'Donnell <rory.odonn...@oracle.com>
>>> wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> Any issues to report on JDK 13 , would like to hear the status as we
>>>> are
>>>> now in rampdown phase 2 ?
>>>>
>>>> **OpenJDK builds *- JDK 13 Early Access build 30 **is now available
>>>> **at
>>>> : - jdk.java.net/13/*
>>>>
>>>> * Per the JDK 13 schedule [1], we are now in Rampdown Phase Two.
>>>> o For more details , see Mark Reinhold's email to jdk-dev mailing
>>>> list [2]
>>>> o The overall feature set is frozen, no further JEPs will be
>>>> targeted to this release.
>>>> o Per the JDK Release Process [3] we now turn our focus to P1 and
>>>> P2 bugs.
>>>>
>>>> * I want to draw your attention to some noteable changes in previous
>>>> builds of JDK 13. These changes are important for those that
>>>> develop/maintain their own socket implementation
>>>> (java.net.SocketImpl) or use the setSocketImplFactory or
>>>> setSocketFactory APIs to change the system-wide socket
>>>> implementation:
>>>>
>>>> o http://jdk.java.net/13/release-notes#JDK-8224477 - delivered in
>>>> build 23
>>>> o http://jdk.java.net/13/release-notes#JDK-8216978 - delivered in
>>>> build 20
>>>> o http://jdk.java.net/13/release-notes#JDK-8220493 - delivered in
>>>> build 13
>>>>
>>>> **OpenJDK builds *- JDK 14 Early Access build 6 is **now available **at
>>>> : - jdk.java.net/14/*
>>>>
>>>> * These early-access, open-source builds are provided under the
>>>> o GNU General Public License, version 2, with the Classpath
>>>> Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
>>>> * Changes of interest since last email
>>>> o 8225239: Refactor NetworkInterface lookups
>>>> o 8226409: Enable argument profiling for sun.misc.Unsafe.put*/get*
>>>> * JEP targeted to JDK 14:
>>>> o JEP352: Non-Volatile Mapped
>>>> * Bug fixes reported by Open Source Projects :
>>>> o JDK-8227080 - fixed in b5 -reported by Eclipse Jetty
>>>>
>>>> The Java Crypto Roadmap
>>>> <https://www.java.com/en/jre-jdk-cryptoroadmap.html> has been updated :
>>>>
>>>> * Released - 16-July-2019 - Release Affected JDK 7u231 - Disabled
>>>> Kerberos DES encryption by default
>>>> * Targeted Date - 2020 - Targeted Release - JDK 8 - Transport Layer
>>>> Security (TLS) 1.3
>>>>
>>>> Rgds,Rory
>>>>
>>>> [1] http://openjdk.java.net/projects/jdk/13/#Schedule
>>>> [2]
>>>> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-July/003170.html
>>>>
>>>>
>>>> --
>>>> Rgds, Rory O'Donnell
>>>> Quality Engineering Manager
>>>> Oracle EMEA, Dublin, Ireland
>>>>
>>>> --
>> Rgds, Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA, Dublin, Ireland
>>
>>
>>
>
