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

[Roland McGrath]

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