> and most importantly perhaps the key reference implementation of
> mktime(),

mktime() has a reference implementation?  I thought the spec was a
standards document, not a reference implementation.

>> [Encountering nonexistent times is] not pretty, but [is] a fact
>> that's approximately inescapable given how the world's current
>> timekeeping systems work.
> It's not only not pretty, it's impossible to recover from such a
> mktime() failure in any sane way given that the timezone rules are
> currently hidden internally in the implementation of mktime() et al.

That's something I disagree with.  You can portably probe for
nonexistent times by calling mktime() and checking for either failure
or tm_* values that don't match what you passed in.  You can portably
probe for duplicated times by calling mktime twice with tm_isdst
complemented and seeing if both results match what you passed in.
Probing for the size and exact location of the gap/overlap is harder,
but is rarely called for.

> That's why mktime() must gracefully give as sane an answer as it can

What is the difference between, upon being asked for 01:30, returning
02:00, 02:30, 00:30, or failure?  They are all different ways of
telling the application "this time does not exist"; they only way I can
see them as differing is what effects they have on code that doesn't
bother to deal with nonexistent times, or code that sloppily tries to
apply absolute deltas by doing wall-clock arithmetic instead of time_t
arithmetic.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B