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@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.