bug in mktime() normalization?

[Alan Perry]

>   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.

alan perry