🚀 go-pugleaf

Paul Eggert (eggert@twinsun.com) writes:
> Let me try to construct a sharper example of the problem.
> 
> Suppose the implementation uses
> tm_isdst=1 to denote the usual 1-hour offset,
> tm_isdst=2 to denote a 2-hour offset,
> and larger values to denote other DST offsets.
> Suppose also that I'm in Newfoundland (2-hour DST in summer 1988),
[Northern Hemisphere summer, of course.]
> and I want to compute the time 1 year after
> 1987-07-01 00:00:00 tm_isdst=1, so I add 1 to tm_year and invoke mktime on
> 1988-07-01 00:00:00 tm_isdst=1.

Once again: "1 year after" usually calls for the same wall clock time on
the date 1 year later, and if that's what you're doing you must set the
member tm_isdst to a negative value.

If you leave the tm_isdst member as 1, you are asking for the time 365*24
or 366*24 hours later, as the case may be.  And in *that* case,

> You

(meaning me)

> seem to be saying that mktime must yield 1988-07-01 00:00:00 tm_isdst=2.

On the contrary, I say mktime() must yield 1988-07-01 01:00:00 tm_isdst=2
in this situation on this implementation.

> But this seems inconsistent with the
> conventional interpretation, which says that
> mktime must adjust 2 hours for DST change when converting from
> 1988-07-01 00:00:00 tm_isdst=0 to
> 1988-06-30 22:00:00 tm_isdst=2.

Would you believe 1988-07-01 02:00:00 tm_isdst=2?

> And if so, shouldn't mktime make the same sort of adjustment if the
> implementation uses tm_isdst values of 3600 and 7200 instead of 1 and 2?

I'm not sure what this means in this context; is it also based on
a misunderstanding of what I (thought I) said before?
-- 
Mark Brader, msb@sq.com         "But I do't have a '' key o my termial."
SoftQuad Inc., Toronto                                     -- Lynn Gold

My text in this article is in the public domain.