>> But how could something HAVE those times as local time-of-day on
>> those dates?
> It doesn't have them -- it tries to create them by doing arithmetic
> on the struct tm fields to try and calculate wall-clock time for some
> offset from some other time which it does "have".

Any program which works this way *must* be prepared to encounter
nonexistent times - or else be prepared to fall over when used in
timezones and at times such that nonexistent times can occur.

That's not pretty, but it's a fact that's approximately inescapable
given how the world's current timekeeping systems work.

If you want "the time 24 hours in the future", you want to do
arithmetic on a time_t (and the hh:mm time will shift by an hour if you
cross a summer-time change point); if you want "the same hh:mm next
day", you have to decide what you want to have happen if "next day" has
other than exactly one "the same hh:mm" (none, in a spring-forward gap;
two, in a fall-back overlap), and then implement that.  Depending on
mktime to cover your failure to do so is just plain sloppy coding.
(Not that sloppy coding has no place, but sloppiness in application
code should not drive decisions about what mktime does.)

> I've written several programs which worked that way.

This makes little odds either way; "how much of Greg Woods' code
breaks" is unlikely to be high on the list of criteria for determining
what NetBSD does in this circumstance.

>> But whouldn't it be better to fix programs that mess around w/
>> impossible times?
> That's just simply not possible.

I'll take your word for it, though it seems unlikely; very little is
truly "not possible" in software.  But it doesn't really matter,
because the fundamental problem is that the code is making assumptions
that simply do not match the realities of timekeeping in DST-using
timezones.

> They're not broken in non-DST timezones.

This is like writing code that assumes a month has >=30 days and then
protesting "it's not broken in non-February months".  DST-using
timezones _do_ occur, just as do Februarys, however inconvenient they
may be for application authors.

/~\ 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