A brief history of (and agenda for) time zone libraries

Roland McGrath roland at gnu.ai.mit.edu
Sat May 15 22:14:01 UTC 1993

> Olson's 1989 code.
> The original timezone code was written by Arthur David Olson.  This public
> domain code has a good reputation.  Even the Posix standard comes as close as
> a standard can to saying ``This is good stuff -- check it out!''; see Posix
> 1003.1-1990 section B.8.1.1, lines 4195-4201.  The most famous publication of
> Olson's code was in comp.sources.unix 18, 111-117 (19 April 1989) -- see
> ftp.uu.net:/usenet/comp.sources.unix/volume18/localtime3/*.

I wish I had known that this code was being maintained, and where to get it
from, before now.

> Proposal.
> Olson's changes should be propagated into both Linux and the GNU C library.

Indeed.  Linux is not my concern, but I plan to update glibc today.

> The GNU C library changes fall into two categories: (A) changes to
> Olson's localtime.c, and (B) everything else.  Merging (B) is easy,
> almost as easy as merging the Linux timezone code, and I've already
> submitted patches to the GNU C library developers to do this.  Merging
> (A) is harder, since the GNU C library has split up localtime.c into lots
> of little pieces.  The GNU C library changes generally improve Olson's
> code -- they make the module interfaces cleaner, and the code is easier
> to follow.  

These issues are very important to the GNU project, and to me.

> Unfortunately, it is now hard to tell how to propagate Olson's
> localtime.c changes and improvements into the GNU C library.  The best
> person to do this propagation is the person who split up localtime.c in
> the first place.

I am that person, and I plan to do the work.

> Another possibility is for the GNU C library to switch to a version of
> localtime.c that is as close as possible to Olson's latest version; that
> might simplify future maintenance.

I really don't want to do this.  It took me quite a while to untangle the
spaghetti in the first place.  This would certainly not simplify
maintenance of the glibc code; it would return it to the obfuscated
spaghetti I started with.  Having the code be modular and clean simplifies
maintenance for me.  Using code close Olsen's code only simplifies future
merging with Olsen's code.

More information about the tz mailing list