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@netvision.net.il> To: "Thomas Carey" <tcarey@bluetrain.com> Cc: <srinivas@broadsoft.com>; "Time Zone Mailing List (E-mail)" <tz@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