🚀 go-pugleaf

msb@sq.com (Mark Brader) writes:

> If you wanted the time one day later, you would have set tm_isdst to -1.

I don't see how this follows.  If I want the time one day later,
the natural thing for me to do is to add 1 to tm_mday.  E.g.:
 
	time_t t0 = time (0), t1;
	struct tm tm = *localtime (&t0);
	tm.tm_mday++;
	t1 = mktime (&tm);

You seem to be saying that the C Standard requires that the above code
not obey my intent in some relatively common cases.  But I can't see
anything in the C Standard that requires the behavior that you describe;
mktime just isn't specified with that degree of precision.

The behavior that you describe can have even stranger results --
e.g. I can add 1 to tm_year and have mktime still give me a time in the
same year as when I started.  I admit that mktime is _allowed_ to do this,
but I don't see where mktime is _required_ to.

> an implementation that could deal with Newfoundland could legitimately
> use distinct positive values for tm_isdst to indicate the 2-hour DST
> of 1988 vs. the 1-hour DST of other years.

An interesting idea, and it leads to interesting probl... -- er, I mean
consequences.  For example, the C Standard allows an implementation
where localtime sets tm_isdst to the DST offset in seconds.
But then suppose we have such an implementation, and suppose that the
user is in US Pacific time and invokes mktime on 1995-01-01 00:00:00
tm_isdst==1.  Then the most logical result for mktime, if we follow
what you seem to be saying, would be 1994-12-31 23:59:59 tm_isdst==0.

I think the C Standard allows this behavior as well.  But then I'm
pretty permissive in these matters.  After all, the standard says ``The
local time zone and Daylight Saving Time are implementation-defined.''
This means that pretty much anything goes.

>> I don't know what the standard means when it says ``the final
>> value of tm_mday is not set until tm_mon and tm_year are determined.''

> I think it means that February 31 becomes March 3 (or 2, as the case may be).

I agree that 02-31 becomes 03-02 or 03-03, but I still don't understand
why the quoted phrase is in the C Standard, particularly when the
``as-if'' rule is taken into account.  Suppose the standard didn't have
the phrase I quoted above.  What implementations would be allowed that are
now prohibited, and why?

Or, to look at another way, suppose we restrict our attention to
implementations that support leap seconds, and suppose we then add to
the C Standard the phrase ``the final value of tm_sec is not set until
tm_min, tm_hour, tm_mday, tm_mon, and tm_year are determined.''  What
leap-second implementations are prohibited by this new restriction that
are allowed by the actual C Standard?  And why does the C Standard treat
tm_sec differently from tm_mday, since the situations are analogous?


The more I think about mktime, the murkier it gets.