Hello, Where can I find the specification for the format of the files within the TZ database? I am developing a Delphi (pascal) program to do time zone conversions, using the TZ database. Faithfully, Sean B. Durkin
The "tzfile.5.txt" file that's part of the ftp://elsie.nci.nih.gov/pub/tzcode2007a.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata2007a.tar.gz archives is your safest bet for the binary files; the "zic.8.txt" file is your safest bet for the source files. --ado -----Original Message----- From: Sean B. Durkin [mailto:sean@dataprocessors.com.au] Sent: Sunday, January 21, 2007 7:25 PM To: TZ Subject: TZ database format specification Hello, Where can I find the specification for the format of the files within the TZ database? I am developing a Delphi (pascal) program to do time zone conversions, using the TZ database. Faithfully, Sean B. Durkin
To anyone who can help: The data source file 'australasia' specifies that the Australia/Darwin zone uses the rule Aus from 1-May-1899 onwards. But the Aus rule is undefined for from 1945 onwards! I have copied the salient fragment of the australasia file to the bottom of this message. Am I missing something here? or is the data inconsistent? Moreover, as a general rule, how should one interpret the application of a tz "rule" for periods when the rule is not explicitly defined? Thanks in advance, if anyone can advise. Faithfully, Sean B. Durkin Fragment from 'australasia' =========================== # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Aus 1917 only - Jan 1 0:01 1:00 - Rule Aus 1917 only - Mar 25 2:00 0 - Rule Aus 1942 only - Jan 1 2:00 1:00 - Rule Aus 1942 only - Mar 29 2:00 0 - Rule Aus 1942 only - Sep 27 2:00 1:00 - Rule Aus 1943 1944 - Mar lastSun 2:00 0 - Rule Aus 1943 only - Oct 3 2:00 1:00 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] # Northern Territory Zone Australia/Darwin 8:43:20 - LMT 1895 Feb 9:00 - CST 1899 May 9:30 Aus CST
On Tue, Jan 23, 2007 at 12:01:19PM +1100, Sean B. Durkin wrote:
The data source file 'australasia' specifies that the Australia/Darwin zone uses the rule Aus from 1-May-1899 onwards. But the Aus rule is undefined for from 1945 onwards! I have copied the salient fragment of the australasia file to the bottom of this message.
Am I missing something here? or is the data inconsistent?
The data specifies when transitions between different UTC offsets occur. Since the Aus rule specifies no transitions after 1943-10-03, and the Austrailia/Darwin zone specifies no other rulset to use after that time, the interpretation is that the UTC offset for the Darwin zone has remained unchanged since 1943-10-03.
Moreover, as a general rule, how should one interpret the application of a tz "rule" for periods when the rule is not explicitly defined?
For times after the last defined rule: that there are no transitions to apply, so the offset from UTC continues on unchanged from what it became on the last specified transition. For times before the first defined rule: that the earliest "standard time" ("SAVE == 0") rule applies. --Ken Pizzini
On Mon, Jan 22, 2007 at 05:46:35PM -0800, Ken Pizzini wrote:
the Darwin zone has remained unchanged since 1943-10-03.
Sorry... sloppy reading of the data on my part: this should have referenced the temporally last transition of 1944-03-26 (lastSun), not the textually last transition in the dataset for the Aus rule. --Ken Pizzini
Date: Tue, 23 Jan 2007 12:01:19 +1100 From: "Sean B. Durkin" <sean@dataprocessors.com.au> Message-ID: <45B55E5F.9070509@dataprocessors.com.au> | To anyone who can help: | | The data source file 'australasia' specifies that the Australia/Darwin | zone uses the rule Aus from 1-May-1899 onwards. But the Aus rule is | undefined for from 1945 onwards! No, it isn't. Clearly we need to do some more work on the documentation, because people keep on making this mistake. Did you read the latest specification for the formats) That recently had some changes made to attempt to make this clearer... If you read that, and it still isn't clear, then perhaps some more changes are needed (though I am not sure exactly how that could be done while remaining reasonably concise.) | Moreover, as a general rule, how should one interpret the application | of a tz "rule" for periods when the rule is not explicitly defined? You have exposed the misunderstanding here. The rules do not specify periods. They specify transitions. That is, they specify instants of time at which wallclocks suddenty jump from one display to another, instead of progressing naturally forward second by second. That's all they specify, they most certainly do not specify a period during which summer time (or daylight saving, or any other name it has in a particular locality at a particular period - "war time" and others). Atempting to do that would not be nearly flexible enough, as it wouldn't easily cope with zones where the standard time offset alters, and other things like that. So if you take ... | Fragment from 'australasia' | # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S | Rule Aus 1917 only - Jan 1 0:01 1:00 - That says, that on Jan 1 1917, at 00:01, the clock jumped to 01:01 | Rule Aus 1917 only - Mar 25 2:00 0 - and this one days that on Mar 25, 1917, at 02:00, the clock jumped back to 01:00. If those were the only rules that existed, people might perhaps understand this more easily, but we also have ... | Rule Aus 1943 1944 - Mar lastSun 2:00 0 - which appears to specify a period (from 1943 to 1944) - yet when you think about, it really does nothing of the kind, there is/was no single timezone offset that applied from March 1943 to March 1944 (much less a single offset in that approximate year that was different from what was before and after it). Rather, that rule is just a shorthand to say that on the last Sunday of March, 1943 (Mar 28) thwre was a transition back to standard time (the clocks moved backwards 1 hour), and the same thing also happened on the last Sunday of March 1944 (Marsh 26th). Clearly those two events make no sense, unless there was also a transition to summer time between them (which there was, and which is found in a different rule). So, this rule line cannot be specifying a period, rather it us specifying the dates at which two different periods ended, and two other periods started - ie: it is specifying two transition points. As soon as you grasp that the rules work like this, you can see that it simply is not possible to have undefined periods - all time either is, or is not, a transition point. The transition points are listed in the rules, every other time is simply a normal time, at which no transition takes place. It happens that the Northern Territory has had a fairly placid timezone experience since the end of the 2nd world war, so there are no more transitions to be found for it, and its timesone remains as set by the last occurring transition, which makkens to be the March 26, 1944 transition mentioned above, which left it with the +09:30 offset. Does this help? kre
All, I wish to reopen the debate about the Australian Time Zone acronyms (EST versus AEST versus EDT versus AEDT). In the TZ database, the acronyms for the "Australian Eastern Standard Time"/ "Australian Eastern Daylight-Saving Time" time zone seasons is given as EST/EST. It is similar the for Central Time and Western Time (CST/CST and WST/WST respectively. The source file for australia discusses the case for these acronyms and also the case for alternative acronyms: (a) EST/EDT; and (b) AEST/AEDT. It looks like Mr.Olsen has settled on EST/EST because there is no legislative support for any official acronyms, and EST/EST is the most widely used. Within the source file, the Bureau of Meterology's web page on the subject ("http://www.bom.gov.au/climate/averages/tables/daysavtm.shtml") was mentioned in passing, however not any more was said of it. I believe that this web page should be given more weight than it has been given. This page shows that the Bureau of Meterology uses EST/EDT rather than EST/EST. Given a perusal of all the other web pages mentioned in the source file, I believe that this page represents the closest thing we can get to an "official" set of acronyms. I would like to make the case for using AEST/AEDT as the acronyms. Here are some points to consider, which have not been noted in the source file. (1) PRACTICAL. Even when the context of Australia is know, EST/EST makes it impractical to record times in the local clock with the acronym. For example in an event is recorded in the Australia/Sydney time zone as "2-Apr-2006 02:30 EST", and the context of "Australia" is given, what does this mean? It is ambiguous. It could be taken to mean either: (a) 1-Apr-2006 15:30 GMT; or (b) 1-Apr-2006 16:30 GMT. I suggest that it would be better to have a pair of acronyms that could be used to differentiate standard time from daylight saving time. I acknowledge that there has already been considerable discussion on the relative importance of having unambiguous acronyms, but that was in the wider context of all time-zones. The point that I am trying to make here is the advantage of unambiguous acronyms just in the case where the time zone is already known as Australia/Sydney. (2) CONSISTENCY WITH GOVERNMENT ORGANS. To be consistent with the treatment of other timezones, we should go with the closest thing to the official acronym, rather than the most popular one. I acknowledge that there is no legislatively official acronyms, but a mentioned earlier, the Bureau of Meterology's usage of EST/EDT is close. However the Bureaus' intended readership is Australian readers. It is not too hard to extrapolate from their full spelling of the seasons "Australian Eastern Standard Time" and "Australian Eastern Daylight Time", that had their audience been more international, that they would have written the obvious acronyms AEST and AEDT. I respectfully propose using AEST/AEDT, ACST/ACDT and AWST/AWDT as acronyms for the respective Australian time zones within the TZ database. Faithfully, Sean B. Durkin
"Sean B. Durkin" <sean@dataprocessors.com.au> writes:
Even when the context of Australia is known, EST/EST makes it impractical to record times in the local clock with the acronym.
Absolutely.
To be consistent with the treatment of other timezones, we should go with the closest thing to the official acronym, rather than the most popular one. I acknowledge that there is no legislatively official acronyms,
That may be, but there is at least one legislatively official phrase that uses "summer time" rather than "daylight time", so it'd be a bit odd for us to use an acronym ending in "DT". See the South Australian Daylight Saving Regulations 2006 <http://www.legislation.sa.gov.au/LZ/C/R/DAYLIGHT%20SAVING%20REGULATIONS%2020...> which says that it's called "South Australian summer time". Presumably the corresponding acronym would be "SAST". But nobody uses "SAST". The only reference I can find to "SAST" was <http://www.linuxsa.org.au/pipermail/linuxsa/1999-November/010423.html>, where Glen Turner notes this exact situation and basically says nobody uses "SAST". I'm not sure I'd use the Bureau of Metrology as an authority in this particular matter. Among other things <http://www.bom.gov.au/climate/averages/tables/dst_times.shtml> bluntly states "The Bureau of Meteorology does not have responsibility for managing Daylight Saving Time." What a mess, huh? I do sense that Australians may be drifting towards the AEST/AEDT style abbreviations, at least in Internet documents. See, for example: http://www.australia.gov.au/about-australia-13time Also, the Google query "ACDT site:gov.au" has about 50,800 hits, apparently because www.abc.gov.au's style guide now says to use "ACDT". In contrast, the query "CDT site:gov.au" has about 26,400 hits and "CST site:gov.au" has about 29,500 hits. So at least the federal government seems to somewhat prefer the ACDT abbreviation. This could well just be due to the style guide at one government news site, though, so I'm not inclined to say this survey is definitive. If Australians are actually switching to AEST/AEDT, at some point we'll probably have to change the tz database. Not at all sure it's there yet, though. The last time I suggested such a change, it was pretty controversial.
Date: Wed, 24 Jan 2007 14:06:23 +1100 From: "Sean B. Durkin" <sean@dataprocessors.com.au> Message-ID: <45B6CD2F.2030100@dataprocessors.com.au> | I wish to reopen the debate about the Australian Time Zone acronyms | (EST versus AEST versus EDT versus AEDT). Do we really have to? This debate happens over and over, and (for good reason) nothing changes, so why waste time doing it again? | In the TZ database, the acronyms for the "Australian Eastern Standard Time"/ | "Australian Eastern Daylight-Saving Time" time zone seasons is given as | EST/EST. There is no such thing as "daylight saving" time in Australia, Australia has Summer Time, which is really quite intelligent on two levels. First because the very concept "daylight saving" is nonsense (not that that would matter much by itself, and other countries certainly use that terminology) and second, precisely because it makes the acronyms for the timezone be unchanged, regardless of whether summer time is in force or not, which is a *good* thing. | This page | shows that the Bureau of Meterology uses EST/EDT rather than EST/EST. I am not quite sure I see the particular relevance of this, the Bureau of Met do some things better than most people, but anything related to time isn't one of them - time keeping isn't one of their tasks. | (1) PRACTICAL. | Even when the context of Australia is know, EST/EST makes it impractical | to record times in the local clock with the acronym. No it doesn't, it is perfectly practical to record times this way. What you mean, is that it is impractical to then attempt to invert that recording, using the zone abbreviation to tell you the timezone offset. That's true, and that's good - about the one thing that we usually do have fairly good agreement on that touches on this issue is that using time zone name abbreviations for anything other than display to users is a truly stupid thing to do (they're not unique, half of them are simply invented by us with very little rationale, and what's more, users can, and occasionally do, define their own for whatever purpose they like). From this I'd conclude that anything that makes it more difficult for programmers to attempt to use the abbreviation for anything other than display to users is a good thing, and certainly not something we should be trying to "fix". | For example in an event is recorded in the Australia/Sydney time zone as | "2-Apr-2006 02:30 EST", and the context of "Australia" is given, what | does this | mean? It is ambiguous. It could be taken to mean either: | (a) 1-Apr-2006 15:30 GMT; or | (b) 1-Apr-2006 16:30 GMT. No, if you know it is Australia/Sydney you simply ignore the EST completely. We know that summer time does not apply in Sydney in April (or more precisely, did not in 2006, which is all that matters here), and that consequently the timezone offset from UTC was 10 hours. Thus 'b' must be the correct answer to the question. If you didn't know it was a Sydney timestamp, then you wouldn't have any idea at all, the "EST" just isn't enough information by itself to achieve anything. If you used March 1st (or 2nd) instead of April, then again, if you knew it was Sydney, you'd know it must have been Summer time, because in 2006 Summer time was in use in Sydney at the start of March. And again, if you don't know it was Sydney, you know nothing at all (worse here as the problem is immediately obvious, as Brisbane would also be EST, and not be Summer Time). I know what you're suggesting is that if EDT was used, you'd know if it was summer time or not, but that's only if you know it is Australia you're talking about. To make this kind of system generally applicable, we'd need to have a worldwide unique set of timezone abbreviations, and some authority to assign abbreviations to zones (worldwide) - much the same as the ISO 3166 group does to the country name abbreviations (the group that decided Australia should be AU and Austria should be AT). That is, people would be told that they're required to use the abbreviations assigned, rather than the ones they're used to - and for Australia, it almost certainly couldn't be just EST (with or without an A on the front, and with or without the D meaning Summer Time) - because Sumemr Time in Tasmania is different than Summer time in the rest of the eastern states, or has been in the past, and could be again - and if you're intending to be able to use the abbreviation to uniquely identify a timezone, you're going to have to have different ones for different zones. Fortunately, it turns out that we don't need any such thing - or rather, we already have exactly what we need, without authorities, and without having to alter what users like to see - that is, if you want to be unambiguous in a way that software can process the time string, and generate the correct UTC equivalent, you just use +1000 or +1100 instead of the alphabetic timezone. It is easy, precise, and gives you exactly what you're looking for, | I suggest that it would be better to have a pair of acronyms that could | be used to differentiate standard time from daylight saving time. Why? In general, that is exactly what we don't want to do, and is, I suspect, exactly why the Australian legislators chose "Summer Time" as the name for the "non standard" timezone - precisely so there was no need to differentiate, it is simply "wallclock time" which is either N, or N+1 hours offset from UTC (and yes, N can be fractional...) | The point that I am trying to make here | is the advantage of unambiguous acronyms just in the case where the time | zone is already known as Australia/Sydney. In that case you're already done. Once you know that, the abbreviation isn't needed at all, the date and time are all that are required to let you know whether standard time, or summer time, was in use. Solved... | | (2) CONSISTENCY WITH GOVERNMENT ORGANS. | To be consistent with the treatment of other timezones, we should go | with the closest thing to the official acronym, rather than the most popular | one. Actually, that's the precise opposite of the general goals of the tz project, we mostly ignore "official" pronouncements, and stick with what is actually used. Further, that position actually defeats your purpose, as ... | I acknowledge that there is no legislatively official acronyms, You're right, but there are legislatively official zone names, and in all the Aust cases I've looked at (I haven't seen the ACT or Tas legislation), the time during summer, from X to Y (which unfortunately keep changing...) is known as "Summer Time". In Vic the act of Parliament is even called the "Summer Time Act", though not every state follows that convention. If you read the recent WA bill, you'd even see that they refer to "Daylight Saving" and stuff in the preamble, but then call it Summer Time when it is defined. It is Summer Time in NSW as well, and, I am fairly sure in South Aus. The time, and argument to make, to the tz project, to get the acronyms changed, would be when you can (reasonably) argue that the popular usage in Australia is to use D instead of S for summer time, not when you can find a single semi-govt web site (for a non-time based dept organisation what's more) and say "well they use D, I like D, change to D please..." | It is not | too hard to extrapolate from their full spelling of the seasons | "Australian Eastern Standard Time" and "Australian Eastern Daylight Time", | that had their audience been more international, that they would have | written the obvious acronyms AEST and AEDT. You mean that we should do what they do, except when you don't like it, then we should do what they obviously would do if they were thinking straight??? The leading 'A' is a whole different issue to S/D debate. However many of the same arguments still apply - it isn't necessary, because the abbreviations aren't useful anyway, and never need to be useful in the way you seem to think they should be. However, it is clear, that in an international context, we sometimes need to make it clear what timezone we're talking about, and "Australian Eastern Standard Time" is a reasonable way to do that, as is "United States Eastern Standard Time" - once I would have said "North American Eastern Standard Time", but (even ignoring the oddball US counties) it isn't clear (yet) that any such concept is going to remain - we don't know if Mexico and (all) the Caribbean Islands are going to copy the new US rules. But when it comes to the abbreviation, why would it be A for Australia? Why wouldn't A mean any of the other countries whose name starts with A? Australia is hardly unique that way... When someone sees AEST, surely it would be reasonable for them to conclude that means Standard Time in the UAE (which has AE as its country code). Surely, if we're going to start throwing around country abbreviations in timezone abbreviations, we should be using the generally accepted abbreviation for the country, which for Australia, is certainly not an unadorned A. What's more, if we did decide we should do that, then we should do it for all the timezone abbreviations, not just those in Aust. kre
On 1/25/07, Robert Elz <kre@munnari.oz.au> wrote:
There is no such thing as "daylight saving" time in Australia, Australia has Summer Time, which is really quite intelligent on two levels.
"EST" is the time zone commonly used in Sydney. 'S' is understood to mean Standard or Summer (not "Sydney" - though it may happen with increasing parochialism).
it is simply "wallclock time" which is either N, or N+1 hours offset from UTC (and yes, N can be fractional...)
My fellow voters in the federal electorate of Sydney (in Lord Howe Island) adjust by 0:30. Regards, Eric Ulevik
participants (6)
-
Eric Ulevik -
Ken Pizzini -
Olson, Arthur David (NIH/NCI) [E] -
Paul Eggert -
Robert Elz -
Sean B. Durkin