<div dir="ltr">Finally, could you please confirm that is there anything wrong in my code?<div>Still i did not understand why this test case is failing with new 2020a tz.<br><div> @Test<br> public void doesNotFallBackToMinus8InDawsonNovember2020() {<br> DateTimeZone timezone = DateTimeZone.forID("America/Dawson");<br> Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, timezone)<br> .withLaterOffsetAtOverlap()<br> .toInstant();<br> Instant day = new DateTime(2020, 11, 1, 0, 0, timezone)<br> .withLaterOffsetAtOverlap()<br> .toInstant();<br> long dayAfterOffset = timezone.getOffset(dayAfter.getMillis());<br> int dayAfterHours = (int) TimeUnit.MILLISECONDS.toHours(dayAfterOffset);<br> long offsetOnDay = timezone.getOffset(day.getMillis());<br> int hoursOnDay = (int) TimeUnit.MILLISECONDS.toHours(offsetOnDay);<br> assertEquals(hoursOnDay, dayAfterHours);<br> }<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 21, 2020 at 3:31 AM Paul Eggert <<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/20/20 4:32 AM, Sundar Sarma wrote:<br>
> The above test case according to your update (will not fall back on <br>
> 2020-11-01) is correct. But test case is failing.<br>
<br>
My guess is that you didn't propagate the data into Java. Java doesn't <br>
use tzdata's TZif files directly; it builds and installs its own copy of <br>
the files and uses that. If Java's copy is obsolete then Java programs <br>
will report obsolete results. For more about this see <br>
<<a href="https://data.iana.org/time-zones/tz-link.html" rel="noreferrer" target="_blank">https://data.iana.org/time-zones/tz-link.html</a>> and look for "Oracle Java".<br>
<br>
You can test this by running the shell command:<br>
<br>
zdump -v -c 2020,2021 America/Dawson<br>
<br>
If older tzdata is installed you'll see this:<br>
<br>
$ zdump -v -c 2020,2022 America/Dawson<br>
America/Dawson -9223372036854775808 = NULL<br>
America/Dawson -9223372036854689408 = NULL<br>
America/Dawson Sun Mar 8 09:59:59 2020 UTC = Sun Mar 8 01:59:59 2020 <br>
PST isdst=0 gmtoff=-28800<br>
America/Dawson Sun Mar 8 10:00:00 2020 UTC = Sun Mar 8 03:00:00 2020 <br>
PDT isdst=1 gmtoff=-25200<br>
America/Dawson Sun Nov 1 08:59:59 2020 UTC = Sun Nov 1 01:59:59 2020 <br>
PDT isdst=1 gmtoff=-25200<br>
America/Dawson Sun Nov 1 09:00:00 2020 UTC = Sun Nov 1 01:00:00 2020 <br>
PST isdst=0 gmtoff=-28800<br>
America/Dawson Sun Mar 14 09:59:59 2021 UTC = Sun Mar 14 01:59:59 2021 <br>
PST isdst=0 gmtoff=-28800<br>
America/Dawson Sun Mar 14 10:00:00 2021 UTC = Sun Mar 14 03:00:00 2021 <br>
PDT isdst=1 gmtoff=-25200<br>
America/Dawson Sun Nov 7 08:59:59 2021 UTC = Sun Nov 7 01:59:59 2021 <br>
PDT isdst=1 gmtoff=-25200<br>
America/Dawson Sun Nov 7 09:00:00 2021 UTC = Sun Nov 7 01:00:00 2021 <br>
PST isdst=0 gmtoff=-28800<br>
America/Dawson 9223372036854689407 = NULL<br>
America/Dawson 9223372036854775807 = NULL<br>
<br>
with transitions continuing this fall and next year. In tzdata 2020a <br>
you'll see this:<br>
<br>
$ zdump -v -c 2020,2022 America/Dawson<br>
America/Dawson -9223372036854775808 = NULL<br>
America/Dawson -9223372036854689408 = NULL<br>
America/Dawson Sun Mar 8 09:59:59 2020 UT = Sun Mar 8 01:59:59 2020 <br>
PST isdst=0 gmtoff=-28800<br>
America/Dawson Sun Mar 8 10:00:00 2020 UT = Sun Mar 8 03:00:00 2020 <br>
MST isdst=0 gmtoff=-25200<br>
America/Dawson 9223372036854689407 = NULL<br>
America/Dawson 9223372036854775807 = NULL<br>
<br>
with transitions stopping after March of this year, and Yukon observing <br>
MST now. If you see the latter output then your tzdata is up-to-date; if <br>
Java is reporting incorrect results in this area then the problem has <br>
something to do with the Java installation, which is downstream from us.<br>
</blockquote></div>