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 'tzcode2002c.tar.gz' and
'tzdata2002c.tar.gz' by building and (after minor modification)
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'.
The files 'localtime', 'posixrules', 'Factory', 'zone.tab' and 'iso3166.tab'
were removed.
Hard links were removed by doing a `cp -R' of the final archive to a
different directory, and then using that directory.  We removed hard
links just because RPM (red hat package manager) seems to have
problems with hard links.

1. The tarballs were unpacked.

mkdir /tmp/tz
cd /tmp/tz
# Fetch tarballs via ftp
tar -xzf tzcode2002c.tar.gz
tar -xzf tzdata2002c.tar.gz

2. The software was built (with tzcode2002c, tzdata2002c, on
GNU/Linux)

make

3. GNUstep timezone information was appended to the file 'etcetera' in order
to provide GMT+/- timezones in OPENSTEP (common usage) format rather than
Posix format (the Posix style timezones are created in the 'Etc' subdirectory).

chmod u+w etcetera
cat $GNUSTEP_SYSTEM_ROOT/Libraries/Resources/NSTimeZones/GNUstep_zones >> etcetera

4. The old information (if any) was removed and the timezone files
were generated and installed (you may need to be logged in as root for
file permissions).

rm -rf /usr/local/etc/zoneinfo
make install

5. The timezone information was copied into the GNUstep zones directory, and
everything we don't want was removed.

cd $GNUSTEP_SYSTEM_ROOT/Libraries/Resources/NSTimeZones
(cd /usr/local/etc; tar -cf - zoneinfo) | tar -xvf -
rm -rf zones
mv zoneinfo zones
(cd zones; rm -rf localtime posixrules Factory zone.tab iso3166.tab)

6. A temporary list of all the zone names was created

find zones -type f -print | sed -e 's/zones\///' > /tmp/tz/zone_names

7. The create_abbrevs and create_regions files were built
'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.

make

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

obj/create-abbrevs `cat /tmp/tz/zone_names` > abbreviations

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

obj/create-regions `cat /tmp/tz/zone_names` > regions

10. Finally, I tidied up.

rm -rf /tmp/tz
make distclean

11. hard links in the `zone' directory were purged

cp -R zones zones.new
rm -Rf zones
mv zones.new zones

12. The .tar file to be included in the gnustep base distribution 
was simply obtained at this point by running tar on the 
$GNUSTEP_SYSTEM_ROOT/Libraries/Resources/NSTimeZones directory:

cd $GNUSTEP_SYSTEM_ROOT/Libraries/Resources/
tar cfv NSTimeZones.tar NSTimeZones

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 August 2000 by R Frith-Macdoanld
Updated (minor) January 2001 by Nicola Pero
Updated (minor) September 2001 by R Frith-Macdoanld
Updated (minor) March 2002 by R Frith-Macdoanld
Updated (minor) September 2002 by R Frith-Macdoanld
