[tz] Precise meaning of FROM and TO in a rule

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-0001.html>