This complete implementation of NSTimeZone uses the time zone data at
<ftp://elsie.nci.nih.gov/pub/>.

Structure of time zone directory:

NSTimeZones/
	abbreviations - Abbreviation map file
	regions - Regions grouped by latitude
	zones/ - Saves the files with the time zones

Install the 'NSTimeZones/' directory in GNUSTEP_INSTALL_LIBDIR
(e.g. if you configured the library with "./configure
--prefix=/usr/local", then install it in '/usr/local/lib/gnustep/').

The file in 'zones/' was created from 'tzcode1999b.tar.gz' and
'tzdata1999b.tar.gz' by building and installing the software in those
tarballs .  The install process places the timezone files in
/usr/local/etc/zoneinfo by default, so they were copied from there to
'zones' and the files 'localtime', 'posixrules', 'Factory',
'zone.tab' and 'iso3166.tab' were removed.

The 'abbreviations' file was created by running 'create-abbrevs' with
the arguments set to all the possible time zone names.

The 'regions' file was created by running 'create-regions' with the
arguments set to all the possible time zone names.

'create-regions' and 'create-abbrevs' only work on systems with the
GNU C library (e.g. Linux).  This isn't a problem since the
distributed files work on any system.

Possible questions
=======================
Why do I use the time zone data at <ftp://elsie.nci.nih.gov/pub/>
instead of using system functions for working with time zones?

First, time zone names sometimes differ from system to system (Linux
has "Asia/Seoul", which the Solaris installation I use doesn't).

Second, at least for strict POSIX the system functions are woefully
inadequate.  There is no reliable way to obtain the offset from UTC,
there is absolutely no way to find out what time zone details there
may be (short of sorting through all time), no way to find a time zone
name from an abbreviation, etc.

Another question that may be asked is why I implemented a new
NSTimeZone when there is already a nearly complete implementation in
the GNUstep Base Library.

The answer is that some of the unimplemented parts are the most
important parts, and there is no way to implement them without a
horrendous cost in memory use.  In that implementation, EVERY time
zone must have an entry in the time zone dictionary, and each time
zone must have a somewhat complicated object associated with it in
order to obtain the appropriate time zone detail for a date, and this
can easily reach a megabyte (the time zone data files altogether
occupy about half a megabyte).

In addition, a new file format must be created for the implementation
(or at least use archiving), which makes things harder since we would
have to code a program that converts the time zone data available at
the above FTP site to the new file format (unless we decide to
maintain the time zone data ourselves, which is not only redundant,
but also would take a whole lot of time).

And most importantly, why did I do this at all?  Because I wanted to
get rid of the "Unable to load TimeZones from data file" message
whenever I got an assertion error. :)


=======================
Yoo C. Chung <wacko@laplace.snu.ac.kr>

Updated 1999 by R Frith-Macdoanld

