Not that I know of... but I've considered it. The ideal situation would be to take this database and put it under the Win32 APIs. Unfortunately, this is not simple because the Win32 APIs don't understand that time zone rules vary from year to year.
Depends on the API. "FileTimeToSystemTime()" doesn't care, just as "localtime()" doesn't care, and "SystemTimeToFileTime()" doesn't care, just as "mktime()" doesn't care; however, "GetTimeZoneInformation()" *does* care - but, then, so does part of the SV time zone API - all you get from it is "timezone", "altzone", and "daylight". Basically, the fields of a "TIME_ZONE_INFORMATION" structure on Win32 correspond to SV variables roughly as: Bias (daylight? altzone : timezone) StandardName tzname[0] StandardDate not available StandardBias timezone DaylightName tzname[1] DaylightDate not available DaylightBias altzone "StandardDate" and "DaylightDate" are tricky, but you could probably set them to the rules for the most recent transitions, or for the next transitions, when "GetTimeZoneInformation()" is called. It might be some work to infer that a POSIX-style rule was in effect, letting you do a day-of-month version of "TIME_ZONE_INFORMATION"... ...but, if the Olson code is ever changed to handle times that don't expire in 2038, it *might* make sense to, instead of just recording transition dates/times, record things like from this date to that date, the rule is this POSIX-style rule; from the previous date to this date, the rule is this other POSIX-style rule; from the previous date to this date, the rule is that it changes on this date at this time; etc., as a compression scheme, so that you don't just store a set of transition times from Jan 1 1970 00:00:00 UTC to 2^63 seconds after that, or whatever. In effect, you'd store the "Rule" entries, rather than the results of running those rules repeatedly. With a scheme like that, coughing up POSIX-style rule information would be easier. It can still handle rules that change from year to year, but if the rules don't change every year, you can have a single entry cover multiple years.
Chris Sells <csells@sellsbrothers.com> asked:
Has anyone ported zic or related zoneinfo routines to Win32?
Eric Ulevik <eau@ozemail.com.au> answered:
Not that I know of... but I've considered it. The ideal situation would be to take this database and put it under the Win32 APIs. Unfortunately, this is not simple because the Win32 APIs don't understand that time zone rules vary from year to year.
Guy Harris <guy@netapp.com> added:
Depends on the API. <detailled discussion snipped>
Definitively. But, as you outlined, time zone informations are stored on a very well defined location on Win32 (in the registry), and it should be relatively easy to store the correct informations coming from our database to this location. Of course, as you explained very clearly, only the last pair of rules can be registered in Win32. But I think this would be better than the present state of art proposed by Microsoft... I began this porting, because I have the same project as Chris, plus another: making the database available in iCalendar format (which was designed to match the datas available in the database): see <ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-ical-08.txt> if you are interested. To do this, I try to split zic.c in two parts: one responsible for the parsing of the text datas, and another, including the main program, responsible for the production of the results. This is not so easy, because some parts are very tightly coupled (but I believe it is doable). This way, it would be easy to write new programs that used the parsed datas (in struct * forms) in other formats, including Win32 registry and iCalendar format). I intend to continue on this way (unless someone already have done extensive work in this area, or unless the group explained to me this is a bad idea). But I shall appreciate any help in working on this. I cannot set up a open mailing list (lack of rights to do so on my host), but I feel a separate mailing list would be more appropriate, at least for the beginning, than this list. Antoine
participants (2)
-
Antoine Leca -
guy@netapp.com