Hi all, I am adding time zone support to our multi-platform application and there are still a few things I cannot figure out. 1) What is the difference between America/Detroit and posix/America/Detroit? The test cases I have written return what looks like the same DST record for a given date no matter which one I use. Under what circumstances would I use posix/America/Detroit? 2) Where is the format of the tz source filesdescribed? Specifically what do SAVE and Letter/S mean below? I am also interested in what the Link format is. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Nic 1979 1980 - Mar Sun>=16 0:00 1:00 D Rule Nic 1979 1980 - Jun Mon>=23 0:00 0 S 3) AIX machines use their own wacky format such at TZ=EST5EDT. Is there any decent mapping to real names? I have googled my brains out on this and searched the comp.time.tz archives on gmane with no luck. Thanks in advance, Donald
Great questions. Answering from memory as I'm away from my system, I think posix/$TZ is the same as $TZ. I recall seeing it generate that way. On a unix system you can likely look at the files under /usr/share/lib/zoneinfo or thereabouts and see exactly. Rather than trying to find sample dates that might reveal differences, try zdump -v (zdump is likely in /usr/sbin). And notation like EST5EDT is the old format, prior to the zoneinfo database, and says it's GMT+5, with no provision for summer time; some vendors try to hardcode summer time rules into their version of libc, which leaves them having to push an emergency code update when the rules get changed.
On Jan 11, 2012, at 1:38 PM, Bennett Todd wrote:
And notation like EST5EDT is the old format, prior to the zoneinfo database, and says it's GMT+5, with no provision for summer time;
Actually, that would be EST5; EST5EDT is GMT+5, with summer time, using some unspecified rules (in practice, whatever happened to be built into the C library; with the Olson code, it's whatever rules came from the "posixrules" file).
I am adding time zone support to our multi-platform application and there are still a few things I cannot figure out.
1) What is the difference between America/Detroit and posix/America/Detroit? The test cases I have written return what looks like the same DST record for a given date no matter which one I use. Under what circumstances would I use posix/America/Detroit?
Guess: "posix" might mean "no leap seconds".
3) AIX machines use their own wacky format such at TZ=EST5EDT. Is there any decent mapping to real names?
No. The real world complexity of timezones is far too great to be represented with that simplistic notation. That's why the Olson tables exist. paul
Donald MacQueen wrote:
1) What is the difference between America/Detroit and posix/America/Detroit?
They're the same thing, but you're not meant to use names starting "posix/" as timezone names. The "posix/" prefix is concerned with two different ways a time_t value can be interpreted for post-1972 times: the posix/ files are for the standard way, where time_t encodes a UTC timestamp, and the right/ files are for an alternative, where time_t counts UTC seconds linearly. The two differ around leap seconds. Short version: you want the posix/ files, don't touch right/ unless you understood the above, and the timezone is named "America/Detroit" and not "posix/America/Detroit".
2) Where is the format of the tz source filesdescribed?
Not formally described anywhere. zic.c is canonical in interpreting it, but it's not the easiest code to read.
SAVE and Letter/S mean below?
SAVE says how far ahead of the zone's "standard" time clocks should be set for the period covered by that rule. SAVE=1:00 is the usual DST value, and SAVE=0:00 means DST is not in effect. LETTER/S provides some letters that can be included in the zone abbreviation specified by FORMAT. The US rules have letters "S" for standard and "D" for DST, and America/Detroit specifies format "E%sT", yielding abbreviations "EST" and "EDT". Many zones don't use this facility, and put a complete abbreviation into FORMAT.
I am also interested in what the Link format is.
A Link means that two zone names are synonymous. E.g., "Link America/Denver America/Shiprock" defines America/Shiprock as an alias for America/Denver; America/Denver is described elsewhere in the file.
3) AIX machines use their own wacky format such at TZ=EST5EDT. Is there any decent mapping to real names?
"EST5EDT" is a POSIX standard format for $TZ, specifying standard and DST offsets and abbreviations. It can (and should) have a further clause added to specify a rule for transition dates, but it's only a single rule for all years. Olson tzfiles (in version 2) actually use this format internally, to specify how to handle dates beyond the enumerated transitions; you can pull this data out with "tail -n1 /usr/share/zoneinfo/America/Detroit", for example. In general a POSIX-format $TZ value cannot be converted to an Olson zone name, because it's ambiguous. For example, "EST5EDT" (even with the transition rule) is ambiguous between America/Detroit and America/New_York, which behave differently in the past. However, AIX is a little more complicated. For certain specifically-recognised POSIX-format $TZ values, lacking explicit DST transition rules, it knows the proper transition rule for some civil timezone that has a nearly-matching offset and abbreviation. Actually the abbreviations in the zone name often don't match the abbreviations actually used in those civil timezones, and in some cases the offset is wrong. I looked into this a few months ago, and came up with this translation table, which I believe covers all the special AIX values: AIX value means CUT0GDT CUT0 GMT0BST Europe/London WET0WEST WET AZOREST1AZOREDT Atlantic/Azores FALKST2FALKDT Atlantic/Stanley GRNLNDST3GRNLNDDT America/Godthab AST4ADT America/Campo_Grande EST5EDT America/New_York CST6CDT America/Chicago MST7MDT America/Denver PST8PDT America/Los_Angeles AST9ADT America/Anchorage HST10HDT Pacific/Honolulu BST11BDT America/Adak NZST-12NZDT Pacific/Auckland MET-11METDT Pacific/Guadalcanal EET-10EETDT Australia/Sydney JST-9JSTDT Asia/Tokyo KORST-9KORDT Asia/Seoul WAUST-8WAUDT Australia/Perth TAIST-8TAIDT Asia/Taipei THAIST-7THAIDT Asia/Bangkok TASHST-6TASHDT Asia/Tashkent PAKST-5PAKDT Asia/Karachi WST-4WDT Asia/Muscat MEST-3MEDT Europe/Istanbul SAUST-3SAUDT Asia/Riyadh EET-2EEST EET USAST-2USADT Africa/Johannesburg CET-1CEST CET The "CUT0" meaning is actually another POSIX $TZ value, not an Olson name, and it refers to constant UT+0h, with no DST, and constant abbreviation "CUT". In some cases the choice of Olson zone is a bit arbitrary, such as for America/New_York. Not having an AIX system myself, I'm not clear on whether AIX implements the historical progression of DST rules for each zone, which would distinguish the ambiguous cases. I'm likewise not clear whether, where the abbreviations are wrong, AIX uses the abbreviation in the zone name (as POSIX requires) or uses the correct abbreviation. I'd be interested to see the results of "zdump -v" on AIX for its special zone names. Best mail me off-list if you acquire this output, because it'll be a bit big. I understand that recent AIX supports Olson zones, so you shouldn't need to stick with "EST5EDT"-like names. -zefram
On 1/11/2012 4:57 PM, Zefram wrote:
Donald MacQueen wrote:
1) What is the difference between America/Detroit and posix/America/Detroit? They're the same thing, but you're not meant to use names starting "posix/" as timezone names. The "posix/" prefix is concerned with two different ways a time_t value can be interpreted for post-1972 times: the posix/ files are for the standard way, where time_t encodes a UTC timestamp, and the right/ files are for an alternative, where time_t counts UTC seconds linearly. The two differ around leap seconds.
Short version: you want the posix/ files, don't touch right/ unless you understood the above, and the timezone is named "America/Detroit" and not "posix/America/Detroit". Tight. I understand that right/ has leap seconds in it and my code will deal with that.
But if posix/America/Detroit and America/Detroit are the same, what is the point of even having posix/America/Detroit? I have sent you some AIX output off list. Thanks for your help.
2) Where is the format of the tz source filesdescribed? Not formally described anywhere. zic.c is canonical in interpreting it, but it's not the easiest code to read.
SAVE and Letter/S mean below? SAVE says how far ahead of the zone's "standard" time clocks should be set for the period covered by that rule. SAVE=1:00 is the usual DST value, and SAVE=0:00 means DST is not in effect.
LETTER/S provides some letters that can be included in the zone abbreviation specified by FORMAT. The US rules have letters "S" for standard and "D" for DST, and America/Detroit specifies format "E%sT", yielding abbreviations "EST" and "EDT". Many zones don't use this facility, and put a complete abbreviation into FORMAT.
I am also interested in what the Link format is. A Link means that two zone names are synonymous. E.g., "Link America/Denver America/Shiprock" defines America/Shiprock as an alias for America/Denver; America/Denver is described elsewhere in the file.
3) AIX machines use their own wacky format such at TZ=EST5EDT. Is there any decent mapping to real names? "EST5EDT" is a POSIX standard format for $TZ, specifying standard and DST offsets and abbreviations. It can (and should) have a further clause added to specify a rule for transition dates, but it's only a single rule for all years. Olson tzfiles (in version 2) actually use this format internally, to specify how to handle dates beyond the enumerated transitions; you can pull this data out with "tail -n1 /usr/share/zoneinfo/America/Detroit", for example.
In general a POSIX-format $TZ value cannot be converted to an Olson zone name, because it's ambiguous. For example, "EST5EDT" (even with the transition rule) is ambiguous between America/Detroit and America/New_York, which behave differently in the past.
However, AIX is a little more complicated. For certain specifically-recognised POSIX-format $TZ values, lacking explicit DST transition rules, it knows the proper transition rule for some civil timezone that has a nearly-matching offset and abbreviation. Actually the abbreviations in the zone name often don't match the abbreviations actually used in those civil timezones, and in some cases the offset is wrong. I looked into this a few months ago, and came up with this translation table, which I believe covers all the special AIX values:
AIX value means CUT0GDT CUT0 GMT0BST Europe/London WET0WEST WET AZOREST1AZOREDT Atlantic/Azores FALKST2FALKDT Atlantic/Stanley GRNLNDST3GRNLNDDT America/Godthab AST4ADT America/Campo_Grande EST5EDT America/New_York CST6CDT America/Chicago MST7MDT America/Denver PST8PDT America/Los_Angeles AST9ADT America/Anchorage HST10HDT Pacific/Honolulu BST11BDT America/Adak NZST-12NZDT Pacific/Auckland MET-11METDT Pacific/Guadalcanal EET-10EETDT Australia/Sydney JST-9JSTDT Asia/Tokyo KORST-9KORDT Asia/Seoul WAUST-8WAUDT Australia/Perth TAIST-8TAIDT Asia/Taipei THAIST-7THAIDT Asia/Bangkok TASHST-6TASHDT Asia/Tashkent PAKST-5PAKDT Asia/Karachi WST-4WDT Asia/Muscat MEST-3MEDT Europe/Istanbul SAUST-3SAUDT Asia/Riyadh EET-2EEST EET USAST-2USADT Africa/Johannesburg CET-1CEST CET
The "CUT0" meaning is actually another POSIX $TZ value, not an Olson name, and it refers to constant UT+0h, with no DST, and constant abbreviation "CUT". In some cases the choice of Olson zone is a bit arbitrary, such as for America/New_York. Not having an AIX system myself, I'm not clear on whether AIX implements the historical progression of DST rules for each zone, which would distinguish the ambiguous cases. I'm likewise not clear whether, where the abbreviations are wrong, AIX uses the abbreviation in the zone name (as POSIX requires) or uses the correct abbreviation.
I'd be interested to see the results of "zdump -v" on AIX for its special zone names. Best mail me off-list if you acquire this output, because it'll be a bit big.
I understand that recent AIX supports Olson zones, so you shouldn't need to stick with "EST5EDT"-like names.
-zefram
-- Donald [|] A bad day in [] is better than a good day in {}
On Sat, Jan 14, 2012 at 11:58, Zefram <zefram@fysh.org> wrote:
Donald MacQueen wrote:
But if posix/America/Detroit and America/Detroit are the same, what is the point of even having posix/America/Detroit?
On a right-based system, America/Detroit will be linked to right/America/Detroit and different from posix/America/Detroit.
Can you elaborate on what it means for a system to be a 'right-based system'? Is there a URL to explain this? (Zefram: sorry for the double-post to you.) -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2011.0612 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
----- Original Message ----- From: Jonathan Leffler To: Zefram Cc: Donald MacQueen ; tz@iana.org Sent: Saturday, January 14, 2012 10:57 PM Subject: Re: [tz] Posix time zone question
Can you elaborate on what it means for a system to be a 'right-based system'?
LANG=C TZ=/usr/share/zoneinfo/posix/America/Detroit date; LANG=C TZ=/usr/share/zoneinfo/right/America/Detroit date Sat Jan 14 17:29:08 EST 2012 Sat Jan 14 17:28:44 EST 2012 It depend if you want to account time with leap seconds or not. Gilles
On Sat 2012-01-14T13:57:18 -0800, Jonathan Leffler hath writ:
Can you elaborate on what it means for a system to be a 'right-based system'? Is there a URL to explain this?
It means that the count of seconds stored in time_t includes every broadcast full-second tick since 1970-01-01T00:00:00, that is, including the leap seconds but not including the fractional second step that happened at 1972-01-01T00:00:00. If I am not mistaken, this means that the value in time_t desired by the "right" zones is the same as is specified by a system which sets its clock using a device conforming to IEEE 1588 (PTP). -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
Donald MacQueen <dmacq@erols.com> writes:
But if posix/America/Detroit and America/Detroit are the same, what is the point of even having posix/America/Detroit?
X is whatever happens to be the default, right/X is explicitly with leap seconds, posix/X is explicitly without them. I seem to recall that identical zones are hardlinked, so having two (or several) files like that only has an overhead of one inode. At least on Linux, I don't know how AIX works in this regard. Thanks, PM
On Jan 16, 2012, at 3:22 PM, Petr Machata wrote:
I seem to recall that identical zones are hardlinked, so having two (or several) files like that only has an overhead of one inode. At least on Linux, I don't know how AIX works in this regard.
AIX might not even ship with the "right" rules; it might ship only with the "posix" ones, and not have the "right" or "posix" directories. (That's how Mac OS X ships - no leap second stuff and no "right" and "posix" directories; "right" and "posix" might be Linuxisms/GNU libc-isms.)
On 2012-01-16 17:47, Guy Harris wrote:
On Jan 16, 2012, at 3:22 PM, Petr Machata wrote:
I seem to recall that identical zones are hardlinked, so having two (or several) files like that only has an overhead of one inode. At least on Linux, I don't know how AIX works in this regard.
AIX might not even ship with the "right" rules; it might ship only with the "posix" ones, and not have the "right" or "posix" directories. (That's how Mac OS X ships - no leap second stuff and no "right" and "posix" directories; "right" and "posix" might be Linuxisms/GNU libc-isms.)
tz code Makefile defaults REDO to posix_right (default posix, alternate right) with commented out values right_posix, posix_only, right_only.
On 16/01/12 23:22, Petr Machata wrote:
I seem to recall that identical zones are hardlinked, so having two (or several) files like that only has an overhead of one inode. At least on Linux, I don't know how AIX works in this regard.
Nit picking: making a hard link to a file creates a directory entry and increments the link count in the inode so the overhead is a directory entry. Another way to think of this is that a file is defined by its inode and it has zero or more names: each name is a directory entry that maps the name to the inode number and the number of names is link count in the inode. I can't imagine that AIX would be any different to any other Unix in this regard. jch
John Haxby <john.haxby@oracle.com> writes:
On 16/01/12 23:22, Petr Machata wrote:
I seem to recall that identical zones are hardlinked, so having two (or several) files like that only has an overhead of one inode. At least on Linux, I don't know how AIX works in this regard.
Nit picking: making a hard link to a file creates a directory entry and increments the link count in the inode so the overhead is a directory entry. Another way to think of this is that a file is defined by its inode and it has zero or more names: each name is a directory entry that maps the name to the inode number and the number of names is link count in the inode. I can't imagine that AIX would be any different to any other Unix in this regard.
It seems I have my vocabulary all mixed up. Thanks for correction. PM
On Wed, Jan 11, 2012 at 2:58 PM, Donald MacQueen <dmacq@erols.com> wrote:
2) Where is the format of the tz source filesdescribed?
The format is explained on the man page for the zic compiler; and there's a plain text version at zic.8.txt in the code subdirectory. I once wrote a little paper, mostly for my own understanding, that you can read at http://www.cstdbill.com/tzdb/tz-how-to.html
I am also interested in what the Link format is.
Do you mean in the source file? If so, then it's Link real-name alias Or do you mean the binaries? If so, then AFAIK it's just another copy of the file. (From what I've seen, it's not really a "link" in the Unix file system sense.) If you're interested in what the binaries look like, check out: http://www.cstdbill.com/tzdb/tzfile-format.html I've posted both of those links on this list before, and nobody has corrected me, so I guess I won't lead you too far astray. 8-) --Bill
On Wed, Jan 11, 2012 at 20:58:38 +0000, Donald MacQueen wrote:
1) What is the difference between America/Detroit and posix/America/Detroit? The test cases I have written return what looks like the same DST record for a given date no matter which one I use. Under what circumstances would I use posix/America/Detroit?
The actual distinction is betweeh "posix" and "right", which differ in whether they account for the existence of leap seconds when counting seconds-since-the-epoch. On a particular system, the default one of those two choices is found in the timezones without a prefix; that default will presumably always match either "posix" or "right". So, for example, on my Debian system there are three "America/Detroit" files. If I run md5sum on each of the three, I see that the no-prefix one matches the "posix' one: $ md5sum `locate Detroit` 17b0eead3047f767a1d8eefa5151308e /usr/share/zoneinfo/America/Detroit 17b0eead3047f767a1d8eefa5151308e /usr/share/zoneinfo/posix/America/Detroit 4c99fc9061e7353cf5310f582a16e428 /usr/share/zoneinfo/right/America/Detroit Assuming your system is the same, it would obviously make sense that your test cases would all return the same result for the two zones you were trying -- but if you compare America/Detroit and right/America/Detroit, you should find some differences...
2) Where is the format of the tz source filesdescribed? Specifically what do SAVE and Letter/S mean below? I am also interested in what the Link format is.
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Nic 1979 1980 - Mar Sun>=16 0:00 1:00 D Rule Nic 1979 1980 - Jun Mon>=23 0:00 0 S
The zic man page (zic.8) documents these fields. Nathan ---------------------------------------------------------------------------- Nathan Stratton Treadway - nathanst@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
participants (13)
-
Bennett Todd -
Bill Seymour -
Brian Inglis -
Donald MacQueen -
Gilles Espinasse -
Guy Harris -
John Haxby -
Jonathan Leffler -
Nathan Stratton Treadway -
Paul_Koning＠Dell.com -
Petr Machata -
Steve Allen -
Zefram