[tz] Is there a high-level conversion process description available?
guy at alum.mit.edu
Sun Oct 23 21:47:56 UTC 2011
On Oct 23, 2011, at 2:01 PM, Willy at willylorenzo.com wrote:
> I was wondering if there exists a high-level description of the process of converting a wall-time from one zone into UTC (and vice-versa) that describes the conversion using the text based zone information (the rules and zones) rather than referencing the binary files.
I doubt it, because I don't know of any implementation of that conversion process.
Even the two conversion processes that are implemented, namely the conversion of the source files to the binary files by zic and the conversion of date/time values give the binary file data, might not have a higher-level description than the source code and the comments.
> If conversions simply can't be done that way because they require additional data that's produced by zic, then I'd like to know that too.
It *could* be done - if nothing else, one could incorporate zic into the library routines, and have it read the source files, write them out to binary files in a temporary directory, and then read in the appropriate binary file - but the source file format is designed to be reasonably easy for humans to write based on specifications of daylight savings time rules, not reasonably easy for localtime() and mktime() to use to convert from UTC to local time, and zic translates from the source format with zones and rules and so on to the binary format with transition times and information about what's being transitioned to (offset from UTC, zone abbreviation, is DST in effect).
zic only reads the source files, so obviously all the data in the binary files comes from the source files; there's no "additional data" that isn't generated from the source files. What zic does, as indicated, is generate, from the source files, the table of transition times and information.
> I'm attempting an implementation of the TZ database in a system called Lotus Notes, which uses a BASIC like language for programming called LotusScript. So I pretty much have to build everything from scratch...which is fine. I‚m going through the archives and I've already found good info there from the recent "Time zone confusion and implementation hints" thread back in July (don't know why Yves Goergen didn't want to install Cygwin...5 minutes after reading that message I had Cygwin installed and was reviewing those tzinfo files!) But I'm still looking for (what seems to be) basic information, such as can the tz code convert 2011-11-06 1:30 AM America/New_York?
Yes, it can - at least if you tell it *which* 2011-11-06 1:30 AM it is.
> That date seems to gets different results based on which converter I use online, as it would appear that you have to know the DST status in order to get the DST status to convert to UTC.
The only local date/time values that are hard to convert are:
1) date/time values that don't exist in local time, because local time leaps forward over that time;
2) date/time values that exist twice in local time, because local time falls backward to that time.
On 2011-11-06 in US regions that have Daylight Savings Time, time falls back at 2AM to 1AM, so there are two 2011-11-06 1:30 AMs in those regions. That's why you have to "know the DST status" - "the DST status" amounts to "is this the first 1:30 AM, which is in DST, or the second 1:30 AM, which is in Standard Time?" For times between 1AM to 2AM on that date, mktime() should look at tm_isdst and, if it's 1 or 0, convert the first or second instance, respectively; I'm not sure whether it picks one, or fails, if tm_isdst is -1. (1 means "this is DST", 0 means "this is standard time", -1 means "figure out which it is", which works for most date/time values, but has a problem with ambiguous values.)
More information about the tz