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