mktime() clarification

[Doug Gwyn]

In article <2404 at unisoft.UUCP> surfdog at unisoft.UUCP (John Onusko) writes:
>What I don't understand is what effect the tm_isdst flag and/or the TZ
>variable has on the output.

TZ is not allowed in a C Standard-conforming run-time environment.
IEEE Std 1003.1-1988 section 8.1.1 specifies the behavior of TZ when
it is defined, in a POSIX environment.  Note that X3J11 rather had
the idea that the standard's "localization" features would be used
instead of UNIX environment variable kludgery.

>	1) should the output time (both time_t and the fixed up tm
>	   struct) be adjusted for DST, if in effect at this time.
>				OR
>	2) is it implied that the user will supply the time in 
>	   the tm struct format, and all that is wanted is a direct
>	   conversion to time_t format. And, the tm_isdst flag is 
>	   returned to the user who then can adjust accordingly.

X3J11/88-159 footnote 135 covers this.  If tm_isdst is nonnegative,
it is input information which mktime() is required to take into account.
(I honestly have no idea how to do that in full generality; I would
assume that it suffices to apply a one-hour shift if DST is said to
be in effect, ignoring any additional time-zone information that you
may have access to.  The input time is not necessarily from the current
time zone.)  If tm_isdst is negative, mktime() is supposed to make its
best guess whether or not DST is in effect for the specified time.  If
it is able to guess, it must set the tm_isdst member to what it used.
It can leave tm_isdst negative if it cannot make a good guess.  (I
think it would be reasonable to use the local time zone for this guess.)

>This brings up a second problem in my quest for correct interpretation.
>When passing tm_isdst flag as input to *presume* initially that DST is/isn't
>in effect. Does...
>	1) a positive value have the same meaning as a negative value,
>	   in that we are observing DST, and a check should be made to
>	   see if DST is in effect. (Just like putting the alternate
>	   timezone "PDT" in the TZ, i.e. TZ=PST8PDT.)

NO!

>	2) a positive value means that that DST is in effect no matter
>	   what time of year it is (like the DST algorithm has been 
>	   changed again), and a negative value means a check for DST
>	   should be made.

YES!

You may have also noticed that the IEEE 1003.1 backward-compatibility
attempt runs into problems with the C standard's namespace antipollution
laws.  It may be tricky to resolve this in your implementation..

Are you aware of ADO's excellent timezone package?  It includes mktime()
etc. and is, if I recall properly, public-domain software.  What it
really excels at is in dealing with a world full of ever-changing and
irrational time zone rules.

P.S.  Not an official X3J11 interpretation.