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