[tz] Precise meaning of FROM and TO in a rule
Arthur David Olson
arthurdavidolson at gmail.com
Tue Jul 8 22:48:00 UTC 2014
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.
@dashdashado
On Tue, Jul 8, 2014 at 6:24 PM, Tim Parenti <tim at timtimeonline.com> wrote:
> On 8 July 2014 02:00, Jon Skeet <skeet at pobox.com> wrote:
>
>> The next part - and where I started - is which year that transition would
>> be assumed to be in.
>
>
> 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.
>
> If you'll indulge me for a moment, my brain refused to explain this to
> myself in a less silly way...
>
> Consider the scattered Kingdom of Foo, which straddles the Prime Meridian:
> Rule Foo 2012 max - Jan Sun>=1 1:00u 1 D
> Rule Foo 2012 max - Jul Sun>=1 1:00u 0 S
> Zone A-Land 1:00 Foo A%sT
> Zone B-Land -3:00 Foo B%sT
>
> 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
> *2011* 22:00 BST --> 23:00 BDT. It appears zic handles this correctly:
>
> $ zdump -vc 2012,2013 A-Land B-Land
> ...
> A-Land Sun Jan 1 00:59:59 2012 UT = Sun Jan 1 01:59:59 2012 AST isdst=0
> A-Land Sun Jan 1 01:00:00 2012 UT = Sun Jan 1 03:00:00 2012 ADT isdst=1
> A-Land Sun Jul 1 00:59:59 2012 UT = Sun Jul 1 02:59:59 2012 ADT isdst=1
> A-Land Sun Jul 1 01:00:00 2012 UT = Sun Jul 1 02:00:00 2012 AST isdst=0
> ...
> B-Land Sun Jan 1 00:59:59 2012 UT = Sat Dec 31 21:59:59 2011 BST isdst=0
> B-Land Sun Jan 1 01:00:00 2012 UT = Sat Dec 31 23:00:00 2011 BDT isdst=1
> B-Land Sun Jul 1 00:59:59 2012 UT = Sat Jun 30 22:59:59 2012 BDT isdst=1
> B-Land Sun Jul 1 01:00:00 2012 UT = Sat Jun 30 22:00:00 2012 BST isdst=0
> ...
>
> A similar case could be made for the equally-dispersed Bar Empire, which
> straddles the International Date Line:
> Rule Bar 2017 max - Jun lastSun 14:00u 1 D
> Rule Bar 2017 max - Dec lastSun 14:00u 0 S
> Zone X-Land -11:00 Bar X%sT
> Zone Y-Land 11:00 Bar Y%sT
>
> 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
> *2018* 02:00 YDT --> 01:00 YST.
>
> $ zdump -vc 2017,2018 X-Land Y-Land
> ...
> X-Land Sun Jun 25 13:59:59 2017 UT = Sun Jun 25 02:59:59 2017 XST isdst=0
> X-Land Sun Jun 25 14:00:00 2017 UT = Sun Jun 25 04:00:00 2017 XDT isdst=1
> X-Land Sun Dec 31 13:59:59 2017 UT = Sun Dec 31 03:59:59 2017 XDT isdst=1
> X-Land Sun Dec 31 14:00:00 2017 UT = Sun Dec 31 03:00:00 2017 XST isdst=0
> ...
> Y-Land Sun Jun 25 13:59:59 2017 UT = Mon Jun 26 00:59:59 2017 YST isdst=0
> Y-Land Sun Jun 25 14:00:00 2017 UT = Mon Jun 26 02:00:00 2017 YDT isdst=1
> Y-Land Sun Dec 31 13:59:59 2017 UT = Mon Jan 1 01:59:59 2018 YDT isdst=1
> Y-Land Sun Dec 31 14:00:00 2017 UT = Mon Jan 1 01:00:00 2018 YST isdst=0
> ...
>
> 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.)
>
> --
> Tim Parenti
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20140708/55453b47/attachment.htm>
More information about the tz
mailing list