Subject: Re: mktime(3) fails to convert a time in the "spring forward gap"
To: None <tech-userlevel@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-userlevel
Date: 10/07/2002 10:33:04
> The practical application might be some tool like at(1) which allows
> the user to specify an offset from some time.  One way to implement a
> delta of a complex offset specification might be to convert both
> times using mktime() and then calculate the difference in the
> resulting time_t values.  Now if the offset happens to put one end of
> the period into a spring forward gap then why should the user be
> essentially told that the calculation of this offset is only valid if
> it's done in certain timezones (eg. in UTC, or Saskatchewan)?

Because it is.  If I ask for the difference between 00:30 and 01:30 for
a date/timezone for which 01:30 doesn't exist, I *should* get failure!

If I ask for 00:30 plus one hour, for a date/zone for which that delta
crosses a spring-forward gap, I should get 02:30.  This means the code
author has to be careful about how "plus one hour" is handled (ie,
time_t+=3600, rather than tm_hour++), but I really can't see anything
wrong with that; it's nothing new for sloppy code to have problems.  If
I ask for 01:30 plus one hour (same date/zone condition), I should get
failure, because 01:30 doesn't exist; I see nothing wrong with getting
an error when trying to work with a time that doesn't exist.

While mktime's interface spec is specifically designed to include cases
where arithmetic has been done on tm_* struct members, producing
normally invalid values, there are problems with trying to "make it
work".  For example, if you're handed tm_hour==1 tm_min==30, is this
one hour before 02:30 (and hence should be resolved to 00:30) or is it
one hour after 00:30 (and hence should be resolved to 02:30)?

> (I really wish DST had never been invented -- what a stupid idea!  We
> should just all live by the Standard Time based on our longtitude,
> i.e. in the originally specified one-hour jumps.  [...])

I actually don't even see any need for timezones; the only use for them
is to keep a given time of the solar day corresponding more or less to
the same numbers.  Admittedly it's not a trivial call whether it's more
pain to have timezones or to have a given numeric time corresponding to
different times of solar day in different places...but it's not a
trivial call the other way either, if you know what I mean.

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