timezone macro for autoconf?

[Russ Allbery]

This is a bit of a digression, and parts of it have more to do with INN
than with the nominal subject of this thread.  In fact, I'll cc this
message to inn-workers at isc.org.  I think it's still on-topic for
comp.unix.programmer and comp.os.linux.development as part of a more
general discussion of programming style, and some of the specific
questions early on about timezones are still relevant to this thread.
Apologies for the rest of the digression.

In gnu.utils.help, Paul Eggert <eggert at twinsun.com> writes:
> Russ Allbery <rra at stanford.edu> writes:

>> ISO C9x, which I was just reading earlier today, actually specifies a
>> new structure, struct tmx,

> struct tmx was in early drafts of ISO C9x, but the spec had a lot of
> problems that were uncovered during review, and struct tmx was removed
> before C99 became official.  struct tmx shouldn't be used in real code.

*grumble*  I really wish they would make the C standard available for
free, or at least for a reasonable price.  I'd gladly purchase a paper
copy, but not for nearly $500.  If it were the price of a typical high-end
technical book, say $60-$80, I'd have a copy of the official standard by
now.

> INN's method is more reliable.  The problem with the 'timezone' method
> is that it assumes that standard time has a fixed UTC offset.  This
> assumption is incorrect.  E.g. Argentina changed their standard-time UTC
> offset last month.

Ah, I'm starting to understand.  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?

But if that's the case, wouldn't taking the difference between localtime
and gmtime also fail, given that the system timezone files likely haven't
been updated?  This also doesn't seem to me to be a common occurance, or
really worth the additional code complexity to work around.  Although I
suppose the code has to be there to handle systems without timezone
anyway.

I still feel like I'm missing something here, though.

> I should point out that I helped to write and debug that part of the INN
> code, so I'm not unbiased here.

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.  It instead uses:

typedef struct _TIMEINFO {
    time_t      time;
    long        usec;
    long        tzone;
} TIMEINFO;

I have a bias when writing code to always, when possible, use the standard
structures and function names, and to put all the portability work into
supplying replacements for the standard ones if they aren't present, so
that the application code as much as possible can look like very standard
C and people don't have to keep hunting up structure definitions to
understand what's going on.

The tzone element of the above struct, which is filled out using the
algorithms we've been discussing on this thread, is currently used in
exactly three places in INN, once in inews to create the default Date
header (which should be done using strftime and some manipulation instead)
and in the parsing of the time argument to NEWGROUPS and NEWNEWS which is
presumed to be in local time unless the client says it's in GMT/UTC.

I'd rather see INN use time_t everywhere internally, or struct timeval if
more accuracy is needed, and use more specific parsing algorithms
specifically for the NEWGROUPS and NEWNEWS time arguments that turn them
into a time_t.  In that place, though, the time zone correction may still
be needed, which requires either tm_gmtoff (definitely the best solution)
or some other means of finding the delta between local time and UTC.

The *best* solution, of course, would be for all news clients to always
send NEWGROUPS and NEWNEWS times in UTC, since using the local time of the
*server* is inherently a flawed way of doing the correction anyway since
the client could be in a different time zone.  If that were done, then the
only place INN would have to worry about timezones at all would be in
parsedate.

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