Okay, so if I've understood you correctly, the date are always as per the wall clock. The time may be specified in standard or UTC, but that doesn't affect how the date part is specified. So just to clarify with a strange example, consider this part of a rule:

Apr Mon>=1 2:00u

So say we're looking for the next transition after 2013-01-01T00:00:00Z, and the current UTC offset is -8. My interpretation of what you've said is that we first identify the local date (2013-04-01, which is a Monday) and then we find the point in time in that 24 hour period at which the UTC time is 02:00. So:

Monday April 1st, 6pm local (before)

Tuesday April 2nd, 2am UTC

I'm pretty sure that Noda Time wouldn't handle that correctly :(

Could you double check my example before I start fixing code? 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 - a whole day early.

I realize that all of this may be academic at the moment - I doubt that there are any rules specified which do have this sort of effect - but I'd rather know about bugs sooner rather than later. It might be an interesting example to try against other implementations, too...

Jon

On 7 July 2014 22: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. A single rule can specify multiple transitions, and it's reinterpreted each time it's used.

Perhaps the following change to zic.8?

diff --git a/zic.8 b/zic.8
index fb8f882..bd9dfeb 100644
--- a/zic.8
+++ b/zic.8
@@ -283,6 +283,7 @@ or
if the given time is universal time;
in the absence of an indicator,
wall clock time is assumed.
+Local time and date is interpreted as of just before the rule takes effect.
.TP
.B SAVE
Gives the amount of time to be added to local standard time when the rule is in