<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"><<a href="mailto:tim@timtimeonline.com" target="_blank">tim@timtimeonline.com</a>></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"><<a href="mailto:skeet@pobox.com" target="_blank">skeet@pobox.com</a>></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'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>=1 1:00u 1 D<br>Rule Foo 2012 max - Jul Sun>=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 --> 03:00 ADT, but in B-Land, this is Sat 31 Dec <b>2011</b> 22:00 BST --> 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 --> 03:00 XST, but in Y-Land, Mon 1 Jan <b>2018</b> 02:00 YDT --> 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>