<div dir="ltr"><div>Arthuritatively speaking, the intent is that rules describe instants when a clock/calendar set to the type of time specified in the AT field would show the specified date and time of day.<br><br></div>    @dashdashado<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 8, 2014 at 6:24 PM, Tim Parenti <span dir="ltr">&lt;<a href="mailto:tim@timtimeonline.com" target="_blank">tim@timtimeonline.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class=""><div class="gmail_extra"><div class="gmail_quote">On 8 July 2014 02:00, Jon Skeet <span dir="ltr">&lt;<a href="mailto:skeet@pobox.com" target="_blank">skeet@pobox.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




The next part - and where I started - is which year that transition would be assumed to be in.</blockquote></div><br></div></div><div class="gmail_extra">Again, I think the years themselves should be in the same frame-of-reference as the months and days, for the same reason.  That is, to apply a rule: For each year between FROM and TO, inclusive (which matches TYPE), find the day-long span corresponding to the date specified by month IN and date ON within that year, according to the frame-of-reference (u/g/z/s/w/blank) specified in AT and the prior offset of the zone; then, find the transition time specified by AT within that span.<br>




<br></div><div class="gmail_extra">If you&#39;ll indulge me for a moment, my brain refused to explain this to myself in a less silly way...<br></div><div class="gmail_extra">
<br></div><div class="gmail_extra">Consider the scattered Kingdom of Foo, which straddles the Prime Meridian:<br>Rule  Foo  2012  max  -  Jan  Sun&gt;=1  1:00u  1  D<br>Rule  Foo  2012  max  -  Jul  Sun&gt;=1  1:00u  0  S<br>




</div><div class="gmail_extra">Zone  A-Land  1:00  Foo  A%sT<br>Zone  B-Land  -3:00  Foo  B%sT<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">One would imagine that the rules should take effect throughout the Kingdom simultaneously; that is, advance at 2012-01-01T01:00Z.  In A-Land, this is Sun 1 Jan 2012 02:00 AST --&gt; 03:00 ADT, but in B-Land, this is Sat 31 Dec <b>2011</b> 22:00 BST --&gt; 23:00 BDT.  It appears zic handles this correctly:<br>




<br>$ zdump -vc 2012,2013 A-Land B-Land<br>...<br>A-Land  Sun Jan  1 00:59:59 2012 UT = Sun Jan  1 01:59:59 2012 AST isdst=0<br>A-Land  Sun Jan  1 01:00:00 2012 UT = Sun Jan  1 03:00:00 2012 ADT isdst=1<br>

A-Land  Sun Jul  1 00:59:59 2012 UT = Sun Jul  1 02:59:59 2012 ADT isdst=1<br>A-Land  Sun Jul  1 01:00:00 2012 UT = Sun Jul  1 02:00:00 2012 AST isdst=0<br>...<br>B-Land  Sun Jan  1 00:59:59 2012 UT = Sat Dec 31 21:59:59 2011 BST isdst=0<br>


B-Land  Sun Jan  1 01:00:00 2012 UT = Sat Dec 31 23:00:00 2011 BDT isdst=1<br>

B-Land  Sun Jul  1 00:59:59 2012 UT = Sat Jun 30 22:59:59 2012 BDT isdst=1<br>B-Land  Sun Jul  1 01:00:00 2012 UT = Sat Jun 30 22:00:00 2012 BST isdst=0<br>...<br><br></div><div class="gmail_extra">A similar case could be made for the equally-dispersed Bar Empire, which straddles the International Date Line:<br>


Rule  Bar  2017  max  -  Jun  lastSun  14:00u  1  D<br>Rule  Bar  2017  max  -  Dec  lastSun  14:00u  0  S<br>

</div><div class="gmail_extra">Zone  X-Land  -11:00  Bar  X%sT<br></div><div class="gmail_extra">Zone  Y-Land  11:00  Bar  Y%sT<br><br></div><div class="gmail_extra">The transition to standard time should occur at 2017-12-31T14:00Z.  In X-Land, Sun 31 Dec 2017 04:00 XDT --&gt; 03:00 XST, but in Y-Land, Mon 1 Jan <b>2018</b> 02:00 YDT --&gt; 01:00 YST.<br>




<br>$ zdump -vc 2017,2018 X-Land Y-Land<br>...<br>X-Land  Sun Jun 25 13:59:59 2017 UT = Sun Jun 25 02:59:59 2017 XST isdst=0<br>X-Land  Sun Jun 25 14:00:00 2017 UT = Sun Jun 25 04:00:00 2017 XDT isdst=1<br>

X-Land  Sun Dec 31 13:59:59 2017 UT = Sun Dec 31 03:59:59 2017 XDT isdst=1<br>X-Land  Sun Dec 31 14:00:00 2017 UT = Sun Dec 31 03:00:00 2017 XST isdst=0<br>...<br>Y-Land  Sun Jun 25 13:59:59 2017 UT = Mon Jun 26 00:59:59 2017 YST isdst=0<br>


Y-Land  Sun Jun 25 14:00:00 2017 UT = Mon Jun 26 02:00:00 2017 YDT isdst=1<br>

Y-Land  Sun Dec 31 13:59:59 2017 UT = Mon Jan  1 01:59:59 2018 YDT isdst=1<br>Y-Land  Sun Dec 31 14:00:00 2017 UT = Mon Jan  1 01:00:00 2018 YST isdst=0<br>...</div><div class="gmail_extra"><br>I agree these particular edge conditions are a bit ridiculous, and probably should be avoided anyway if possible, but it would be good to document the expected behavior here.  (The citizens of Foo and Bar, who simply live for edge cases, will be grateful.  And I can be sure of that because they are, thankfully, fictitious.)<br>




</div><div class="gmail_extra">
<br clear="all"><div>--<br>Tim Parenti<br></div>
</div></div>
</blockquote></div><br></div>