[tz] Welcome to the "tz" mailing list

Sundar Sarma gkssarma59 at gmail.com
Thu May 21 12:39:33 UTC 2020


Finally, could you please confirm that is there anything wrong in my code?
Still i did not understand why this test case is failing with new 2020a tz.
 @Test
    public void doesNotFallBackToMinus8InDawsonNovember2020() {
        DateTimeZone timezone = DateTimeZone.forID("America/Dawson");
        Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, timezone)
                .withLaterOffsetAtOverlap()
                .toInstant();
        Instant day = new DateTime(2020, 11, 1, 0, 0, timezone)
                .withLaterOffsetAtOverlap()
                .toInstant();
        long dayAfterOffset = timezone.getOffset(dayAfter.getMillis());
        int dayAfterHours = (int)
TimeUnit.MILLISECONDS.toHours(dayAfterOffset);
        long offsetOnDay = timezone.getOffset(day.getMillis());
        int hoursOnDay = (int) TimeUnit.MILLISECONDS.toHours(offsetOnDay);
        assertEquals(hoursOnDay, dayAfterHours);
    }

On Thu, May 21, 2020 at 3:31 AM Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 5/20/20 4:32 AM, Sundar Sarma wrote:
> > The above test case according to your update (will not fall back on
> > 2020-11-01) is correct. But test case is failing.
>
> My guess is that you didn't propagate the data into Java. Java doesn't
> use tzdata's TZif files directly; it builds and installs its own copy of
> the files and uses that. If Java's copy is obsolete then Java programs
> will report obsolete results. For more about this see
> <https://data.iana.org/time-zones/tz-link.html> and look for "Oracle
> Java".
>
> You can test this by running the shell command:
>
> zdump -v -c 2020,2021 America/Dawson
>
> If older tzdata is installed you'll see this:
>
> $ zdump -v -c 2020,2022 America/Dawson
> America/Dawson  -9223372036854775808 = NULL
> America/Dawson  -9223372036854689408 = NULL
> America/Dawson  Sun Mar  8 09:59:59 2020 UTC = Sun Mar  8 01:59:59 2020
> PST isdst=0 gmtoff=-28800
> America/Dawson  Sun Mar  8 10:00:00 2020 UTC = Sun Mar  8 03:00:00 2020
> PDT isdst=1 gmtoff=-25200
> America/Dawson  Sun Nov  1 08:59:59 2020 UTC = Sun Nov  1 01:59:59 2020
> PDT isdst=1 gmtoff=-25200
> America/Dawson  Sun Nov  1 09:00:00 2020 UTC = Sun Nov  1 01:00:00 2020
> PST isdst=0 gmtoff=-28800
> America/Dawson  Sun Mar 14 09:59:59 2021 UTC = Sun Mar 14 01:59:59 2021
> PST isdst=0 gmtoff=-28800
> America/Dawson  Sun Mar 14 10:00:00 2021 UTC = Sun Mar 14 03:00:00 2021
> PDT isdst=1 gmtoff=-25200
> America/Dawson  Sun Nov  7 08:59:59 2021 UTC = Sun Nov  7 01:59:59 2021
> PDT isdst=1 gmtoff=-25200
> America/Dawson  Sun Nov  7 09:00:00 2021 UTC = Sun Nov  7 01:00:00 2021
> PST isdst=0 gmtoff=-28800
> America/Dawson  9223372036854689407 = NULL
> America/Dawson  9223372036854775807 = NULL
>
> with transitions continuing this fall and next year. In tzdata 2020a
> you'll see this:
>
> $ zdump -v -c 2020,2022 America/Dawson
> America/Dawson  -9223372036854775808 = NULL
> America/Dawson  -9223372036854689408 = NULL
> America/Dawson  Sun Mar  8 09:59:59 2020 UT = Sun Mar  8 01:59:59 2020
> PST isdst=0 gmtoff=-28800
> America/Dawson  Sun Mar  8 10:00:00 2020 UT = Sun Mar  8 03:00:00 2020
> MST isdst=0 gmtoff=-25200
> America/Dawson  9223372036854689407 = NULL
> America/Dawson  9223372036854775807 = NULL
>
> with transitions stopping after March of this year, and Yukon observing
> MST now. If you see the latter output then your tzdata is up-to-date; if
> Java is reporting incorrect results in this area then the problem has
> something to do with the Java installation, which is downstream from us.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20200521/2715bd22/attachment.html>


More information about the tz mailing list