Porting zoneinfo routines to Win32?

Guy Harris guy at netapp.com
Mon Jul 13 21:53:54 UTC 1998

> 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.

More information about the tz mailing list