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

Arthur David Olson ado
Sat May 15 23:03:03 UTC 1993


> From roland at gnu.ai.mit.edu Sat May 15 18:14:48 1993
> Return-Path: <roland at gnu.ai.mit.edu>
> Received: from churchy.gnu.ai.mit.edu by elsie.nci.nih.gov (4.1/SMI-4.1)
> 	id AA22472; Sat, 15 May 93 18:14:34 EDT
> Received: by churchy.gnu.ai.mit.edu (5.65/4.0)
> 	id <AA21556 at churchy.gnu.ai.mit.edu>; Sat, 15 May 93 18:14:01 -0400
> Date: Sat, 15 May 93 18:14:01 -0400
> From: roland at gnu.ai.mit.edu (Roland McGrath)
> Message-Id: <9305152214.AA21556 at churchy.gnu.ai.mit.edu>
> To: eggert at twinsun.com
> Cc: libc-alpha at gnu.ai.mit.edu, tz at elsie.nci.nih.gov
> Subject: Re: A brief history of (and agenda for) time zone libraries
> In-Reply-To: Paul Eggert's message of  Sat, 15 May 93 00:08:44 PDT <9305150708.AA18312 at bi.twinsun.com>
> X-Shopping-List:    (1) Hot mutant holidays
>    (2) Apologetic interruptions
>    (3) Frenetic lesions
> 
> > 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