🚀 go-pugleaf

In gnu.utils.help, Paul Eggert <eggert@twinsun.com> writes:

> 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.

Ah!  Thank you.  That makes sense.  I can see where that may well make a
difference.

> No standard time structure will do.  Neither struct tm nor struct
> timeval is guaranteed to contain a time zone.

True, but in checking into it, it turns out that INN very rarely actually
uses the timezone.  Getting that information in all of the places that INN
uses timestamps is therefore rather wasteful and pointless.

For a time that doesn't need an associated timezone, I think using time_t
or struct timeval is superior.  I'd really like to isolate the time zone
handling in INN to as few places as possible and just use UTC everywhere
else; I think it makes the code a lot easier to follow.

> 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).

Hm.  Except that I can't figure out how to get a struct timespec on
Solaris or older Linux without just converting a struct timeval, and
gettimeofday() is available nearly everywhere these days and returns a
struct timeval.  Right now, struct timeval looks like the de facto
standard regardless of what the de jure standard says.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>