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

[Tim Parenti]

On 7 July 2014 18:44, Jon Skeet <skeet at pobox.com> wrote:

> I think at the moment I always assume that the time of day and the date
> are in the same frame of reference - so in the above example, I suspect I'd
> find a transition at Monday April 1st, 2am UTC


This, too, is my personal understanding of at least the *intent* behind the
interpretation of years, months, and dates in FROM, TO, TYPE, IN, and ON,
That is, they are to take the same interpretation as the suffix which
applies to AT.

In your example: Since 2:00u is specified for the transition, Apr Mon>=1
should be treated as Universal time, then find 02:00Z within that day.  So
transition Monday 1 April 02:00 UTC, which is Sunday 31 March 18:00 UTC–8.

On 7 July 2014 17:57, Paul Eggert <eggert at cs.ucla.edu> wrote:

> Transitions are given in terms of the local time before the transition, as
> otherwise a transition could be self-referential.


This doesn't seem it should apply to transition rules with "u"/"g"/"z"
suffix; only those with "s" or "w"/no suffix.

"Standard time" rules would be computed similarly to "Universal time"
rules.  Find the span of the specified date in the zone's standard time (as
reckoned by the offset PRIOR to the transition), then find the specified
standard time within that span.

"Wall clock time" rules with no suffix (or a "w" suffix) would find the
span of the date in the zone's wall clock time (as reckoned by the PRIOR
offset), then find the proper wall clock time.

I think this seems the most logical for maintenance and rule-writing, as
any rule specified in, e.g., UTC, ought to recur in UTC.

For a concrete example, see how current EU rules are meant to apply to
America/Godthab.  Transitions occur at Mar lastSun 1:00u and Oct lastSun
1:00u, which should be equivalent to Mar Sat>=24 22:00s and Oct Sat>=24
22:00s.

--
Tim Parenti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20140707/4e89e0c7/attachment.html>