TZ database content

[Thomas Carey]

Christoph
I think not too farfetched. The OS supplied tz functions are inadequate for
the most robust real-world multi-timezone scenarios that modern applications
must support. But it depends how closely linked your application is to a
particular platform. If you run only on windows, then I think it makes sense
to use their routines and timezones, out of the box, so that you integrate
well with other windows applications and the OS. probably same on unix. One
way to support multi-platforms would be to write to your own api which would
wrap the OS supplied routines and data. The problem as you know comes if you
need to share data between platforms.

The other, more radical, approach is to decide which locales/eras you need
to support and make sure that you have the correct information (in some
form) and the functions to access it. This will probably be a subset of
tzdata (or may have information from some other source, in some other
format). Perhaps you'll want rules for the transition, rather than a lookup
table for the transition in particular years. There are many different ways
of solving the problem. Make sure yours meets the needs of your customers.
(The only difficulty I have had with the rule-based solution is with the
rules for daylight savings transition in Tehran, which starts the first day
of Farvardin and ends the first day of Mehr. I just don't know what to do
with that information, so I had to instantiate the dates for this timezone.)

(see http://webexhibits.org/daylightsaving/g.html  for a non-comprehensive
list of DST rules for different timezones.)

The only caveat I'd give is not to be overly attached to a complete and
eternally correct piece of timezone coordinating software. The nature of the
beast is it (or its data) needs to be tweaked occaisionally. Which leads to
my last point. Let me note, in the words of an esteemed colleague, that

    "Political time is a drag."

But, it pays the bills.

tc

----- Original Message -----
From: "Christoph Bugel" <cbugel at netvision.net.il>
To: "Thomas Carey" <tcarey at bluetrain.com>
Cc: <srinivas at broadsoft.com>; "Time Zone Mailing List (E-mail)"
<tz at elsie.nci.nih.gov>
Sent: Friday, February 09, 2001 11:27 AM
Subject: Re: TZ database content


Interesting. We were thinking about a similar approach, in our case we did
not
necessarily care about having identical names. Rather, we want to use the
tzcode implementations of localtime() and mktime() instead of the ones
provided
with the OS(**), This would then require us to have tzdata around, and since
our code must work windoze as well, we need to provide a tzdata with the
product. (tzcode can't read from the registry :).

(**) the reason we thought about using localtime() and mktime() from tzcode
instead of the C library is that we need to have thread safe code that can
work
simultaneously with different timezones.  Normally this would require doing
putenv("TZ") all the time, which causes too much trouble for thread safety.
basically we want something like: struct tm *my_localtime(const time_t
*time,
struct TZ * tz); - i.e., some sort of explicit timezone parameter.. same
goes
for mktime.

I wonder if this is too far fetched.


On Fri 2001-02-09, Thomas Carey wrote:
> Srini - I have found it necessary to take exactly this approach,
incorporating one "snapshot" of the TZ data into our product itself so that
it would work properly everywhere. (our web application takes local time
from the user's computer, but requires explicit (or implicit) selection of
the timezone in effect for each entity to which a timezone applies.)
>
> tc
>   ----- Original Message -----
>   From: Srinivas Nagaraj
>   To: Time Zone Mailing List (E-mail)
>   Sent: Friday, February 09, 2001 9:02 AM
>   Subject: TZ database content
>
>
>   The TZ (zoneinfo) database comes installed with several operating
>   systems like Linux, Solaris, etc.
>
>   I have noticed the content of the TZ database varies between different
>   versions of the same operating system and also between operating
>   systems.  This could have been because of when a snapshot of the
>   TZ database was taken.
>
>   Ofcourse, one significant difference is the actual name of the time
zone.
>   Depending on the content of the TZ database, the time zone name look
>   different.  Is it because the TZ database has evolved?
>
>   I also noticed that the zone.tab file is not distributed on a number of
>   installations.  Was that operating system installation decision?
>
>   Now my main question, is it an appropriate application specific common
>   practice to use an application specific TZ database?  That way the
>   time zone names can be consistent, irrespective of where the application
>   is installed?
>
>   Thank you.
>
>   Srini