Re: CVS commit: src/lib/libc/time

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 19 Jan 2009 13:15:06 +0100
    From:        Matthias Drochner <M.Drochner%fz-juelich.de@localhost>
    Message-ID:  
<200901191215.NAA0000144997%zel459.zel.kfa-juelich.de@localhost>

  | Is there some publicly archived mailing list or so where
  | one could follow development?

Mailing list, yes, certainly, tz%elsie.nci.nih.gov@localhost

It is a members only (spam free) list with an open join policy (anyone
can get on the list) - send mail to Arthur David Olson (ado) at
olsona <at> dc37a.nci.nih.gov to join.   Or just send to the list,
ado will forward your message, and if you want, add you to the list
(it is low volume, fairly small group of people who work pretty hard on
mostly keeping track of the data, there's no automated list management
software in use - this list has been around since the mid 80's essentially
unchanged, other than membership...)

Archived?   Good question, I never thought to wonder, since I've been on
the list essentially forever, and have my own (private) archive.

But yes, it is, I've just taken a look - there's a single file,
ftp://elsie.nci.nih.gov/pub/tzarchive.gz  - it is a mbox format
file of messages on the list, currently from the first message
(message 1) from November 1986, to the most recently added (message 6410)
from Jan 5 this year (there have been another 30-40 messages more
recent than that, I don't know how often tzarchive.gz file is updated,
until now I didn't even know it existed - or I didn't remember anyway - but
as with most of this list, it is probably done manually from ado's
personal copies of the messages whenever he feels the need ...)

And from message 1, it may be that tz-requests%elsie.nci.nih.gov@localhost is
the "correct" address for admin messages, rather than ado's private
mailbox.   (The message says seismo!elsie!tz-requests which gives some
of you some idea of the age of all of this...   That address certainly
is unlikely to work now).

The archive stops before the announcement of the pending release of the
2009a versions of the code and data (the announcement contains the diff
from tzcode2008h and tzdata2008i).  There's a small chance the release
might be delayed, there's a (minor) issue with the proposed tzdata2009a
that is being discussed (one of administrative and historical interest
only, it doesn't affect anyone's timezone conversions.)

One more comment, on messages sent to the list, the address
        tz%lecserver.nci.nih.gov@localhost
often appears in To headers, etc - don't use that one, or any derivative
for it, for anything, that's just a black hole...  (as you may have
gathered, this is not the most high tech of mailing lists around!)

  | Agreed - just had a look at 2008h and it seems
  | to deal correctly with the problems I had seen.

Yes, so should many previous versions...

  | It does some things at runtime which could be
  | done more efficiently.

Yes, though there is some hope the compiler might optimise a lot of
that away - but the intent (like NetBSD) is that the code be portable
to anything imaginable...    For NetBSD, where we know that time_t is
not a floating point type and we know it is signed, not unsigned, etc,
some of that code could be #if'd away (or just deleted).

  | Don't know whether
  | mktime()/localtime() are used a lot in database
  | applications where it would matter.

localtime() might be, and making that one reasonable is probably a good
idea, I doubt mktime() is used enough to worry too much about.  There has
been something of a discussion of that on, (and off) the tz list just
recently (that is some of the extra 30 or so messages) inspired by someone
who does have a need for efficient mktime() for his particular application.
My view is that such users should just roll their own tm->time_t func,
where they can optimise for whatever they need based upon whatever they
know about their own application.

  | In any case it would be better to optimize the new one than
  | to hack our old version to death.

Agreed.

  | Any takers?

I could take a look if no-one else is interested, if you're not all in
an extreme hurry for the result...   (the current fix to make mktime() at
least workable and should hold current for a few weeks, right?)   Someone
else would need to check it, then commit it.

Or anyone else if you're in more of a hurry...   (I do have a couple of
days head start, as I know already what tzcode2009a will be ...)

  | According to doc/3RDPARTY the NetBSD version is 2004a.

Oh.   I didn't think of looking there.   That is old.

I thought I saw some comments in commit logs (cvs log localtime.c etc)
that referred to 2006 versions, which might have indicated that patches
from those have been incorporated, but I might just as easily have
misread (or misremembered) what I saw.

kre