🚀 go-pugleaf

Russ Allbery <rra@stanford.edu> writes:

>So what you're saying is that code based
>on timezone will fail if the definition (in terms of UTC offset) of the
>local timezone has changed since the point at which the daemon was
>started?

No, that's another bug entirely (one that few daemons have fixed).

I was referring to the problem that different time stamps correspond to
different UTC offsets.  E.g. the value for 'timezone' for Portugal
today is 0, since Portugal's standard time is now the same as
Greenwich.  But from 1992 to 1996 Portugal had a standard time one hour
ahead of Greenwich.  So if 'timezone' contains the value zero (which is
correct for Portuguese time stamps today), time_t values between 1992
and 1996 won't be handled correctly in a Portuguese locale.

This problem doesn't occur when comparing the outputs of localtime and
gmtime, since their outputs can (and, in good implementations, do)
use standard-time UTC offsets that depend on the time stamp in question.

>I'm rather unsatisfied with how time is currently handled in INN primarily
>because INN uses its own weird time structure internally rather than
>either just time_t or a struct timeval.

No standard time structure will do.  Neither struct tm nor struct
timeval is guaranteed to contain a time zone.  And when the code was
written, struct timeval wasn't standardized (and it's still absent from
some hosts); time_t plus some other stuff was the only portable way to go.

These days the most "standard" way to write it would be to use struct
timespec, as it's standardized by POSIX.1 (struct timeval is not).
However, the standards are still mutating in this area -- the next C
standard after C99 might well have a new time type -- so personally I'd
just leave INN alone for now.

Your other points are well taken.