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 'tzcode1997e.tar.gz' and
'tzdata1997f.tar.gz'.  The files 'localtime', 'posixrules', 'Factory',
'zone.tab', 'iso3166.tab', and the directories 'posix' and 'right'
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.

For a short period of time, the time zone data for NSTimeZone
directory will be available from
<http://plaza.snu.ac.kr/~wacko/gnustep/> (the current date is 4 June,
1997).

The implementation itself is available as a patch to
gstep-base-970503, and is available at the same place.  (Warning: This
patch also includes changes to many other parts of the library.)


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>
