How to support such capabilites based on current Olson Time Zone implementation

[Martin Dong]

Dear All in this maillist,

We have been investigating the feasibility of migrating Olson Time Zone
Database to our system. Given that our system is Linux-based, we can just
use tzcode implementation or Glibc functions because Glibc has adopted Olson
implementation to some extent. But according to our basic and existing
requirements, I have met some problems that I think are hard for me:

   - How to get the local time of different region or city at the same
   time? The basic requirement is to display the local time of different region
   or city at the same time.

 After some study of Olson implementation, I knew function "localtime" will
handle everything, parsing tzfile and doing the conversion from utc to local
time. The correct local time can be gotten through a simple invocation to
"localtime". But "localtime" assumes the Sytem Local Time Zone is set in
environmental variable "TZ" or from the Standard TimeZone file
"/etc/localtime" if "TZ" is not defined in the process. In this case, how
can a caller get the local time of some city which is not the System Local
Time Zone? It seems we must change "TZ" or the Standard TimeZone file before
calling "localtime" to get another city's local time because "localtime"
doesn't take such an argument that can let caller specify a time zone, which
means "localtime" can return the local time related to either the System
Local Time Zone or the time zone user specifies.

Although I know there're so many applications which already integrates the
Olson Database and they have realized my above requirement "display multiple
local time at the same time", I don't know how they make it.


   - How to get the notification of DST status change as time elaspes?

 This problem is out of our another requirement that we need to inform other
components in our system of the DST status change in various conditions,
such as changing time may lead to DST change, changing local time zone may
lead to DST change, and as time elapsing, etc. The former two behaviors are
user-active ones, we can track the change easily, but the problem is the
last one, it's the system automatic behavior, our of the control of user. In
this case, the system needs some CALLBACK ability to capture this change and
further broadcast it. For our system, there's an Alarm Server that can
provide timer machinasm. We will parse our own time zone database and get
the next nearest DST transition time and add it to Alarm Server, then when
the timer is time out, Alarm Server will trigger a CALLBACK function to
further process.

But it seems Olson is lack of such capability. After thinking from another
perpsective, if we can get the next nearest DST transition time through
Olson Time Zone database, we can still utilize our current Alarm Server. But
it's still a problem how to get the next nearest DST transition time through
the current Olson implementation because all the implementation is hiden
behind "localtime". In all the public functions, there's no such one which
can support getting the DST transition time.

I don't have any good idea in mind right now. Should I make some
modification to Olson to add such capability, or other way i could go?

I will very much appreciate if any of you can give me some hints about above
problems. Thank you in advance.

Best Regards,

-Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20070727/145af57a/attachment-0001.html