<div dir="ltr">Is Yukon part of Canada/Mountain?<div><br></div><div>Regards,</div><div>Sundar</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 20, 2020 at 8:47 PM Brian Inglis <<a href="mailto:Brian.Inglis@systematicsw.ab.ca">Brian.Inglis@systematicsw.ab.ca</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 2020-05-20 05:32, Sundar Sarma wrote:<br>
> According to the latest 2020a tz update: Canada's Yukon, represented by<br>
> America/Whitehorse and<br>
>     America/Dawson, advanced to -07 year-round, beginning with its<br>
>     spring-forward transition on 2020-03-08, and will not fall back on<br>
>     2020-11-01.<br>
> We have written a test cases like below for canada yukon timezone. We imported<br>
> new 2020a tz into our environment.<br>
> Our code seems correct but test cases are failing. So we found that there is<br>
> wrong in Iana tz side.<br>
> Please check and correct us. This is the below code we have written.<br>
> @Test<br>
>     public void doesNotFallBackToMinus8InDawsonNovember2020() {<br>
>         DateTimeZone timezone = DateTimeZone.forID("America/Dawson");<br>
>         Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, timezone)-------> on<br>
> 2nd nov 00:00:00<br>
>                 .withLaterOffsetAtOverlap()<br>
>                 .toInstant();<br>
>         Instant day = new DateTime(2020, 11, 1, 0, 0, timezone)------> on 1 st<br>
> nov 00:00:00<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);  ------->  here we are getting<br>
> error: java.lang.AssertionError: expected:<-7> but was:<-8><br>
>     }<br>
> The above test case according to your update (will not fall back on 2020-11-01)<br>
> is correct. But test case is failing.<br>
> Could you please clarify us that is there anything wrong from IANA tz.<br>
> If not how can i write my test case according to that? <br>
<br>
For a start, you must always take account of the summer transition times forward<br>
and back.<br>
Across Canada, times change at Sunday 02:00 local time: in March, as each time<br>
zone hits 02:00, it becomes 03:00; in November, as each time zone hits 02:00, it<br>
becomes 01:00:<br>
<br>
$ zdump -Vc2020,2021 Canada/Mountain | sed 's/\(Sun\).*\1/\1/'<br>
Canada/Mountain  Sun Mar  8 01:59:59 2020 MST isdst=0 gmtoff=-25200<br>
Canada/Mountain  Sun Mar  8 03:00:00 2020 MDT isdst=1 gmtoff=-21600<br>
Canada/Mountain  Sun Nov  1 01:59:59 2020 MDT isdst=1 gmtoff=-21600<br>
Canada/Mountain  Sun Nov  1 01:00:00 2020 MST isdst=0 gmtoff=-25200<br>
<br>
so to be sure, you need to check on or after each transition, as you will have<br>
ambiguous times on Sunday in March between 01:00 and 02:00, and in November<br>
between 02:00 and 03:00.<br>
In both cases, you could check on or after Sun 03:00.<br>
Checking at 12:00 noon is often chosen to be safe regardless of actual<br>
transition times, which could vary from 00:00 to 06:00.<br>
Similarly, checks are often done on December 31 and June 30 to avoid being near<br>
any northern or southern hemisphere transition dates.<br>
However in recent years Islamic countries have started to reset summer time<br>
changes during Ramadan, which can occur any time in the Gregorian calendar.<br>
<br>
-- <br>
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada<br>
<br>
This email may be disturbing to some readers as it contains<br>
too much technical detail. Reader discretion is advised.<br>
[Data in IEC units and prefixes, physical quantities in SI.]<br>
</blockquote></div>