bug in mktime() normalization?
esprit at best.com
Thu Aug 21 16:08:19 UTC 1997
> Here's what UNIX98 has to say regarding this:
> >From your quote it appears that UNIX98 says the same thing that the C
> Standard says, which is to say, not much. The C Standard spec for
> mktime is terribly ambiguous and you've found one of the ambiguities.
> The C Standard says that mktime can return -1 if attempted in the
> ``spring forward gap'', but it doesn't say how mktime should determine
> whether one is in the gap.
> Any user program that messes in this area is relying on behavior that
> is not guaranteed by any standard. For what it's worth, the GNU C
> library's mktime agrees with the tz mktime on your example, whereas
> Solaris 2.5.1 and BSD/OS 3.0 have the other reasonable interpretation
> (i.e. both mktime invocations yield 575002800).
Back when I worked at Sun on the timezone code, this issue came up and
I could have changed mktime() to return -1 in this case. If I remember
right, the standard says mktime() returns -1 if the time cannot be
represented and, after thinking about, I concluded that the "spring
forward gap" could be represented. As I saw it, the only time that could
not be represented was time outside the range of a time_t.
I didn't think the standards explicitly mentioned this topic, but now that
I no longer work at Sun and don't even work on things remotely related to
what I was doing before, I don't see the current standards much.
More information about the tz