🚀 go-pugleaf

In article <456oti$s0@light.twinsun.com>, eggert@twinsun.com (Paul Eggert) writes:
> I'm writing from memory here, since my copy of the standard is at work,
> but I recall that the standard says only that out-of-range time values
> should be accepted; it doesn't say what should be done with them.

It does say that the components are set to represent the specified time
with the values within the normal ranges.  Between the standard and the
rationale, I think the intent is clear.

> > by the appropriate DST offset and clear the flag.
> 
> I still don't see where the standard requires this.

Perhaps you misunderstood -- I didn't say that the standard is perfectly
clear, I said that I thought the intent was clear.  I think the example
in the rationale makes it clear that this is what was intended.

> There is another plausible way to adjust the time, i.e. simply clear the flag.
> This is better for many common cases (e.g. the ``add 1 day'' example),

Again, it depends on what you mean by ``add 1 day''.  As someone else
(Mark Brader?) already pointed out, if by ``add 1 day'' you mean ``24
hours later'', then you just add 1 to tm_mday; if instead you mean
``same time tomorrow'', then you add 1 to tm_mday and set tm_isdst to
-1.  This lets the programmer specify which interpretation to use, the
other forces a specific interpretation which may not be what the
programmer wants.  (In fact, it makes it impossible to specify ``24
hours later'' without knowing the detailed DST rules.)
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com
Who, ME?  Who?! Me??  WHO... Me?!  Who, me??? -- Calvin