Thanks for the fabulous example of Godthab.

I've confirmed that http://www.timeanddate.com/time/zone/greenland/nuuk, Noda Time and Java 8 all put the next transition at 2014-10-26T01:00:00Z, so 1am Sunday UTC, 11pm Saturday local time. So that's the first thing that should be clarified in the documentation, IMO - assuming that we're happy that is the correct behaviour.

The next part - and where I started - is which year that transition would be assumed to be in. Sure, for October it's not a problem... but imagine the rule had been for the first Sunday in January, with a rule starting in 2012. When would the rule have first applied? Either it wouldn't have applied in 2012 at all, or it would have applied in UTC 2012, which was local 2011 at the point of the transition. Again, I realize this is mostly theoretical - if everyone's happy to agree that we just avoid getting to this edge condition (through careful rule crafting), that'd be great... but should also be documented, I think.

Jon


On 8 July 2014 01:15, Tim Parenti <tim@timtimeonline.com> wrote:
On 7 July 2014 18:44, Jon Skeet <skeet@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@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