Ambiguous abbreviations for Australian timezones when daylight savings is in affect
Hi All, I’d like to bring this very important issue back up for discussion. I’m going to attempt to address the reason why this change is needed as clearly as possible while addressing the concerns from previous discussions. The issue is with both EST (Tasmania, Victoria, New South Wales, Queensland) and CST (South Australia, Northern Territory) It's well past time the Australian abbreviations were updated to reflect the current terms and usage. Stop the confusion and use the abbreviations recommended by the Australian government to try to avoid this mess. http://australia.gov.au/about-australia/our-country/time#daylightsaving As others have posted I’m not too concerned about the 'A' but as you will see differentiating between daylight savings times is extremely important when you are using this information in a system that crosses state boundaries and in our case an emergency warning system. Previous Post: --------------------- “I'm not a big fan of change for change's sake; once the database is one way I like to leave it alone. For phrases, the new statistics seem to be quite strong; for whatever reason, Australians seem to be voting with their feet (or fingers) and are adopting American terminology with an "Australian", when the time zone names are spelled out. For abbreviations, it's not clear whether "AEDT" or "EDT" is more common, though I suppose "AEDT" has a slight edge. I'd like to hear more from Australian correspondents on this before thinking about specific changes, though.” - Paul Eggert (26 Aug 2008) I don’t think anyone here cares deeply enough about time zone abbreviations enough to be arguing about change for change’s sake. The fact is the ambiguity of the current abbreviations for time zones is causing real world problems. Previous Post: --------------------- “Alphabetic time zone abbreviations should not be used as unique identifiers for UTC offsets as they are ambiguous in practice. For example, "EST" denotes 5 hours behind UTC in English-speaking North America, but it denotes 10 or 11 hours ahead of UTC in Australia; and French-speaking North Americans prefer "HNE" to "EST".” - Paul Eggert (26 Aug 2008) The issue is not that the identifiers are not unique worldwide. The problem is that they are not unique to bordering states in the same country which run along the same time zone. Most apply daylight savings time, one (Queensland) does not, this is what causes the confusion. Simply using UTC +10 or UTC +11 is not good enough as the general public has no idea what UTC is. Previous Post: --------------------- “I have always assumed that the common abbreviation (EST for standard time, and EST for summer time) was a very deliberate choice, chosen so that if it ever was appropriate to specify a time with an abbreviated zone name, then the time specified would apply year around, which is almost always what is intended” - Robert Elz (5 Jan 2009) If all states that used EST applied daylight saving then this would be convenient but as stated above they do not. The problem can be seen in the delivery example where it would appear an Australian company does delivery’s via time travel. Previous Post: --------------------- “Queensland don't have Daylight Saving Time. New South Wales (across the border from Queensland) do have Daylight Saving Time. Due to the fact that the Olsen data uses EST for both 'Eastern Summer Time' (New South Wales) and 'Eastern Standard Time' (Queensland), a delivery from New South Wales to Queensland can have a pickup time of 10.30am EST and a delivery time of 10.00am EST. We like to be efficient but we're not that good. System users only see the EST and get horribly confused.” - Mick Johnston (26 Aug 2008) So obviously I’m pushing this for my own reason also. We currently use unix based systems to produce tsunami arrival times for the Australian Tsunami Warning System. This information is displayed on a public webpage (and as described above cannot use UTC convention). The issue comes into play when listing arrival times for the east coast of Australia, simply listing all arrival times as EST will obviously cause confusion especially for towns located near the border of NSW/QLD where it would appear to take a tsunami an extra hour to arrive only a couple of kilometres away. Currently we cannot use the default unix time zone commands and must rely on the use of a script to parse the time zone files and produce EST/EDT abbreviations. Obviously the ideal solution is to fix the EST/CST abbreviations once and for all so the all Australians can finally have software that produces time zones abbreviations that can be read by the general public and be used without having to provide added context. Note: In our organisation alone this issue has been brought up independently by multiple areas. Timothy Arceri
I believe we should have a vote on this, because it comes up too often, and there seem to be a few strong voices that are blocking this from being resolved. The vote should only provide two options: should we stay with the current australian tz abbreviations or not. If not, then we can vote on what we prefer. For those blocking this from being fixed, the most common excuse is that tz is not supposed to impose its own abbreviations upon its users, but by not going with anything the Australians are using - tz is doing exactly that. On 2013-03-27 22:33, Timothy Arceri wrote:
Hi All,
I’d like to bring this very important issue back up for discussion. I’m going to attempt to address the reason why this change is needed as clearly as possible while addressing the concerns from previous discussions. The issue is with both EST (Tasmania, Victoria, New South Wales, Queensland) and CST (South Australia, Northern Territory)
It's well past time the Australian abbreviations were updated to reflect the current terms and usage. Stop the confusion and use the abbreviations recommended by the Australian government to try to avoid this mess.
http://australia.gov.au/about-australia/our-country/time#daylightsaving
As others have posted I’m not too concerned about the 'A' but as you will see differentiating between daylight savings times is extremely important when you are using this information in a system that crosses state boundaries and in our case an emergency warning system.
Previous Post: --------------------- “I'm not a big fan of change for change's sake; once the database is one way I like to leave it alone. For phrases, the new statistics seem to be quite strong; for whatever reason, Australians seem to be voting with their feet (or fingers) and are adopting American terminology with an "Australian", when the time zone names are spelled out. For abbreviations, it's not clear whether "AEDT" or "EDT" is more common, though I suppose "AEDT" has a slight edge.
I'd like to hear more from Australian correspondents on this before thinking about specific changes, though.” - Paul Eggert (26 Aug 2008)
I don’t think anyone here cares deeply enough about time zone abbreviations enough to be arguing about change for change’s sake. The fact is the ambiguity of the current abbreviations for time zones is causing real world problems. Previous Post: --------------------- “Alphabetic time zone abbreviations should not be used as unique identifiers for UTC offsets as they are ambiguous in practice. For example, "EST" denotes 5 hours behind UTC in English-speaking North America, but it denotes 10 or 11 hours ahead of UTC in Australia; and French-speaking North Americans prefer "HNE" to "EST".” - Paul Eggert (26 Aug 2008)
The issue is not that the identifiers are not unique worldwide. The problem is that they are not unique to bordering states in the same country which run along the same time zone. Most apply daylight savings time, one (Queensland) does not, this is what causes the confusion. Simply using UTC +10 or UTC +11 is not good enough as the general public has no idea what UTC is.
Previous Post: --------------------- “I have always assumed that the common abbreviation (EST for standard time, and EST for summer time) was a very deliberate choice, chosen so that if it ever was appropriate to specify a time with an abbreviated zone name, then the time specified would apply year around, which is almost always what is intended” - Robert Elz (5 Jan 2009)
If all states that used EST applied daylight saving then this would be convenient but as stated above they do not. The problem can be seen in the delivery example where it would appear an Australian company does delivery’s via time travel.
Previous Post: --------------------- “Queensland don't have Daylight Saving Time. New South Wales (across the border from Queensland) do have Daylight Saving Time. Due to the fact that the Olsen data uses EST for both 'Eastern Summer Time' (New South Wales) and 'Eastern Standard Time' (Queensland), a delivery from New South Wales to Queensland can have a pickup time of 10.30am EST and a delivery time of 10.00am EST. We like to be efficient but we're not that good. System users only see the EST and get horribly confused.” - Mick Johnston (26 Aug 2008)
So obviously I’m pushing this for my own reason also. We currently use unix based systems to produce tsunami arrival times for the Australian Tsunami Warning System. This information is displayed on a public webpage (and as described above cannot use UTC convention). The issue comes into play when listing arrival times for the east coast of Australia, simply listing all arrival times as EST will obviously cause confusion especially for towns located near the border of NSW/QLD where it would appear to take a tsunami an extra hour to arrive only a couple of kilometres away.
Currently we cannot use the default unix time zone commands and must rely on the use of a script to parse the time zone files and produce EST/EDT abbreviations. Obviously the ideal solution is to fix the EST/CST abbreviations once and for all so the all Australians can finally have software that produces time zones abbreviations that can be read by the general public and be used without having to provide added context.
Note: In our organisation alone this issue has been brought up independently by multiple areas.
Timothy Arceri
--
On Mar 28, 2013, at 9:09 PM, David Patte ₯ wrote:
I believe we should have a vote on this, because it comes up too often, and there seem to be a few strong voices that are blocking this from being resolved. The vote should only provide two options: should we stay with the current australian tz abbreviations or not.
If not, then we can vote on what we prefer.
For those blocking this from being fixed, the most common excuse is that tz is not supposed to impose its own abbreviations upon its users, but by not going with anything the Australians are using - tz is doing exactly that.
I believe the current state of the tz data comes from the observation that there were conflicting statements about Australian practice, with no one clearly more authoritative or prevalent than the others. Given the link posted by Timothy Arceri -- a government website about timezones -- it would seem to make sense to adopt what that says. paul
On 03/29/2013 07:05 AM, Paul_Koning@Dell.com wrote:
Given the link posted by Timothy Arceri -- a government website about timezones
A problem, as we've seen when looking into this before, is that different parts of the Australian national and state governments disagree, and there does not seem to be a consistent consensus. If I understand the recent comments aright (and I admit I haven't had time to digest them) it appears that different parts of the Australian governments continue to use inconsistent names and/or abbreviations.
True, but lets at least adopt the national one until they decide what they would prefer, otherwise we are contributing to the confusion and their own debate. On 2013-03-29 12:38, Paul Eggert wrote:
On 03/29/2013 07:05 AM, Paul_Koning@Dell.com wrote:
Given the link posted by Timothy Arceri -- a government website about timezones
A problem, as we've seen when looking into this before, is that different parts of the Australian national and state governments disagree, and there does not seem to be a consistent consensus. If I understand the recent comments aright (and I admit I haven't had time to digest them) it appears that different parts of the Australian governments continue to use inconsistent names and/or abbreviations.
--
On 03/29/13 10:01, David Patte ₯ wrote:
lets at least adopt the national one
If I recall correctly, the last time I checked, different parts of the Australian national government used different terminology and/or abbreviations and nobody seemed to be in charge. This area of confusion is not new, by the way: The ABC could not be more or less explicit than it was in the term "Eastern Australian daylight saving time," said an official of the commission yesterday, when replying to a statement by a correspondent of The Argus, that the phrase was cumbersome.... The suggestion that the ABC should adopt the term "Eastern summer time" was unsatisfactory... -- "A B C and summer time", The Argus (Melbourne), 1942-10-07, page 5, col. 2. <http://trove.nla.gov.au/ndp/del/article/11999053>
On Sun, Mar 31, 2013 at 3:12 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 03/29/13 10:01, David Patte ₯ wrote:
lets at least adopt the national one
If I recall correctly, the last time I checked, different parts of the Australian national government used different terminology and/or abbreviations and nobody seemed to be in charge.
Correct. There is no higher authority on Australian timezone abbreviations than the tz database maintainer. The most authoritative source of information for Australians (and most of the world) is what their computers tell them. For Australians without computers, the next most authoritative sources would be debatable but I imagine they would be the ABC (National Broadcaster, who you quote from 1942) followed by the Bureau of Meteorology. The State or Federal Governments would be way down the list. I'm afraid you are in a leadership position here. Setting the bar so high as 'until everyone is in agreement' or even 'all parts of the government are in agreement' means it will never happen. I don't think it is sane to think that a federal government, seven state governments, a couple of territories, thousands of municipalities, and an uncountable number of government departments could even agree on the day of the week. If the position really is that it will never change, just make a statement to that effect so we can petition our OS providers to patch the database and move on. -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/
You make a very good point, that unless a usable unambiguous system of abbreviations in tz is adopted for Australia, there is a serious risk of the database becoming fragemented as different OS providers patch the database according to their own preferences, adding to the confusion. It is for this reason I feel strongly that tz has a responsibility to adopt SOME abbreviations that at least differentiate between standard and daylight/summer time, before others users of the database do. Related, are there any estimates of how many computer systems currently use the tz database, and potentially suggest thecurrent ambiguous abbreviations to potential users? in their own way On 2013-03-31 2:24, Stuart Bishop wrote:
If the position really is that it will never change, just make a statement to that effect so we can petition our OS providers to patch the database and move on.
--
[changing the Subject: line] On 03/30/13 23:41, David Patte ₯ wrote:
are there any estimates of how many computer systems currently use the tz database
I'd guess a billion computer systems now, with one or two million activated per day. This compares to a world population of about seven billion people, with about a third of a million babies born every day. At this rate it won't be too long before the lines cross. I should emphasize, though, that the computer counts and projections are merely guesses.
I'd guess almost every modern system except Windows. Including mobile devices, 1B is probably low. Moreover, simply a count of computers doesn't tell the real story. For example, someone can be on Windows but if they are using Google services, they are using the tz database on Google's servers. Mark <https://plus.google.com/114199149796022210033> * * *— Il meglio è l’inimico del bene —* ** On Sun, Mar 31, 2013 at 10:34 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
[changing the Subject: line]
On 03/30/13 23:41, David Patte ₯ wrote:
are there any estimates of how many computer systems currently use the tz database
I'd guess a billion computer systems now, with one or two million activated per day. This compares to a world population of about seven billion people, with about a third of a million babies born every day. At this rate it won't be too long before the lines cross.
I should emphasize, though, that the computer counts and projections are merely guesses.
On Mar 31, 2013, at 2:28 AM, Mark Davis ☕ <mark@macchiato.com> wrote:
I'd guess almost every modern system except Windows. Including mobile devices, 1B is probably low.
For starters, every machine running OS X, every iPhone/iPad/iPod Touch, every Apple TV, every AirPort Extreme/Express/Time Capsule that's running NetBSD (rather than whatever small OS was used before they switched to NetBSD), and, as far as I know, every machine running Android. Then add in servers running Solaris and newer versions of AIX, and PC's running Linux/*BSD/Solaris.
On Sun, Mar 31, 2013 at 12:48 PM, Guy Harris <guy@alum.mit.edu> wrote:
On Mar 31, 2013, at 2:28 AM, Mark Davis ☕ <mark@macchiato.com> wrote:
I'd guess almost every modern system except Windows. Including mobile devices, 1B is probably low.
For starters, every machine running OS X, every iPhone/iPad/iPod Touch, every Apple TV, every AirPort Extreme/Express/Time Capsule that's running NetBSD (rather than whatever small OS was used before they switched to NetBSD), and, as far as I know, every machine running Android.
Then add in servers running Solaris and newer versions of AIX, and PC's running Linux/*BSD/Solaris.
It is embedded into Java: http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html Which would also cover all of the non-PC Java based hardware devices.
Now, David Patte's original question was "how many computer systems currently use the tz database, and potentially suggest the current ambiguous abbreviations to potential users?". At least the volume leaders in tz database use (Android, iOS, Java) don't normally use the abbreviations provided by the tz database - they get long or short display names from CLDR (the Unicode Consortium's Common Locale Data Repository). The numbers discussed here therefore don't have much to do with the relevance of Australian time zone abbreviations in the tz database. Norbert On Mar 31, 2013, at 9:59 , Andrew Paprocki wrote:
On Sun, Mar 31, 2013 at 12:48 PM, Guy Harris <guy@alum.mit.edu> wrote:
On Mar 31, 2013, at 2:28 AM, Mark Davis ☕ <mark@macchiato.com> wrote:
I'd guess almost every modern system except Windows. Including mobile devices, 1B is probably low.
For starters, every machine running OS X, every iPhone/iPad/iPod Touch, every Apple TV, every AirPort Extreme/Express/Time Capsule that's running NetBSD (rather than whatever small OS was used before they switched to NetBSD), and, as far as I know, every machine running Android.
Then add in servers running Solaris and newer versions of AIX, and PC's running Linux/*BSD/Solaris.
It is embedded into Java: http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html
Which would also cover all of the non-PC Java based hardware devices.
Or in short, every computer running a modern OS that has enough user interface to need to present time to people.
On Mar 31, 2013, at 10:34 AM, Bennett Todd <bet@rahul.net> wrote:
Or in short, every computer running a modern OS that has enough user interface to need to present time to people.
I think this: http://windows.microsoft.com/ counts as "a modern OS that has enough user interface to need to present time to people", but, whilst there *are* people from Microsoft on this list, that OS doesn't, as far as I know, use the Olson database. I don't think this: http://www.windowsphone.com/ uses it, either.
Paul Eggert <eggert <at> cs.ucla.edu> writes:
A problem, as we've seen when looking into this before, is that different parts of the Australian national and state governments disagree, and there does not seem to be a consistent consensus. If I understand the recent comments aright (and I admit I haven't had time to digest them) it appears that different parts of the Australian governments continue to use inconsistent names and/or abbreviations.
The links that I have presented in the other thread make it fairly clear that all states *are* using a consistent format for abbreviations. The only thing that is inconsistent is is the use of the full terms daylight savings/summer time although daylight saving is much more commonly used outside of the actual legislation. For completeness here is two more state/territory government website links that uses the Australian government defined format. Northern Territory government page: ----------------------------------- "The Time Zone in the Northern Territory is Australian Central Standard Time (ACST, also commonly referred to as CST). ACST is shared by Broken Hill (NSW), the Northern Territory and South Australia. ACST is 9 hours and 30 minutes ahead of Coordinated Universal Time (UTC)." http://alicesprings.nt.gov.au/alice-springs/timezone Queensland page: ---------------- "The consultation period on the proposed reform, including the legislative package and Consultation Regulatory Impact Statements, will remain open for submissions until 5pm AEDT 12 October 2012 for all occupations." http://mines.industry.qld.gov.au/safety-and-health/national-licensing-consul...
On 03/30/13 03:34, Timothy Arceri wrote:
The links that I have presented in the other thread make it fairly clear that all states *are* using a consistent format for abbreviations.
I'm afraid that doesn't follow. One can easily find disagreements with the contents of those links. For example, you gave a link to the NSW Dept of Attorney General & Justice saying that in summer, eastern time is abbreviated "AEDT". But that very web page also says, in another place, that the abbreviation is "EDST". So this single source contradicts the assertion that abbreviations are consistently used by the NSW government. Here's that URL again: http://www.communityrelations.lawlink.nsw.gov.au/cru/daylight/definitions_of... And the EDST-related quote from that page: "Daylight saving or summer time is commonly expressed as EDST (Eastern Daylight Saving Time)."
On Thu, 28 Mar 2013, David Patte ₯ wrote:
For those blocking this from being fixed, the most common excuse is that tz is not supposed to impose its own abbreviations upon its users, but by not going with anything the Australians are using - tz is doing exactly that.
I don't think that anybody wants the tz database to use different abbreviations from what is in common use in Australia. What's blocking this from being *changed* is that we believe that the existing abbreviations *are* in common use in Australia, but that other abbreviations are also in common use, and we have no good way to choose between the two (or more) sets of abbreviations, so it seems best to retain the status quo. If you want change, then it is incumbent on you to demonstrate that your preferred abbreviations are either in wider use than the alternatives, or have more official government backing than the alternatives. Selective quoting from some web sites does not constitute such a demonstration. --apb (Alan Barrett)
On Mon, Apr 1, 2013 at 12:28 PM, Alan Barrett <apb@cequrux.com> wrote:
On Thu, 28 Mar 2013, David Patte ₯ wrote:
For those blocking this from being fixed, the most common excuse is that tz is not supposed to impose its own abbreviations upon its users, but by not going with anything the Australians are using - tz is doing exactly that.
I don't think that anybody wants the tz database to use different abbreviations from what is in common use in Australia. Then why the IANA timezone database contains EST for Daylight saving time in Eastern Australia?
What's blocking this from being *changed* is that we believe that the existing abbreviations *are* in common use in Australia, Who is "we"? Not even Paul is believing it as shown by his October 2012 message.
but that other abbreviations are also in common use, and we have no good way to choose between the two (or more) sets of abbreviations, so it seems best to retain the status quo.
Again, this is not about just choosing a /new/ set, but it is about one that uses one acronym for each zone during daylight saving time.
If you want change, then it is incumbent on you to demonstrate that your preferred abbreviations are either in wider use than the alternatives, or have more official government backing than the alternatives. Why?
Selective quoting from some web sites does not constitute such a demonstration. How would you demonstrate "official government backing" if not by selecting a subset of official government websites?
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
Date: Mon, 1 Apr 2013 13:07:39 +0200 From: Tobias Conradi <tobias.conradi@gmail.com> Message-ID: <CAAGevbV2o+P0Rw=EPFOkyvBuwp_rZBdBBqUoHCRKF8XuEv2Lhg@mail.gmail.com> | Then why the IANA timezone database contains EST for Daylight saving | time in Eastern Australia? It is "Summer Time" (Eastern Summer Time) which is what it is called in the legislation. It is also (if unimaginative) a rational name, unlike "daylight saving" which is gibberish. | Again, this is not about just choosing a /new/ set, but it is about | one that uses one acronym for each zone during daylight saving time. Why? | How would you demonstrate "official government backing" if not by | selecting a subset of official government websites? You would (presumably) ask the appropriate govt department(s) for a ruling (and appropriate here is nothing from the commonwealth govt, except if you're asking about ACT, and certainly not the Bureau of Met). kre
On Mon, Apr 1, 2013 at 2:20 PM, Robert Elz <kre@munnari.oz.au> wrote:
Date: Mon, 1 Apr 2013 13:07:39 +0200 From: Tobias Conradi <tobias.conradi@gmail.com>
I don't think that anybody wants the tz database to use different abbreviations from what is in common use in Australia.
Then why the IANA timezone database contains EST for Daylight saving time in Eastern Australia?
It is "Summer Time" (Eastern Summer Time) which is what it is called in the legislation. So it is not EST in the legislation? And since when is the name from legislation "common use in Australia"?
Mr Elz?
It is also (if unimaginative) a rational name, unlike "daylight saving" which is gibberish. I would not call EST a name, but more an acronym and it is one used in the IANA timezone database for Eastern non-DST time as well as DST time and that whilst there are points in time where both Eastern DST and Eastern non-DST coexist.
Again, this is not about just choosing a /new/ set, but it is about one that uses one acronym for each zone during daylight saving time.
Why? Because Timothy started the thread that way. And now, if you ask why he wants it that way - there are some reasons given in the starting message.
How would you demonstrate "official government backing" if not by selecting a subset of official government websites?
You would (presumably) ask the appropriate govt department(s) for a ruling And how can the presented in the mailing list and added to the IANA timezone database file australasia? "I had a phone call ...."?
(and appropriate here is nothing from the commonwealth govt, Why?
and certainly not the Bureau of Met). Why?
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
Date: Mon, 1 Apr 2013 14:58:27 +0200 From: Tobias Conradi <tobias.conradi@gmail.com> Message-ID: <CAAGevbX_K5E174-F5PVXuytbA4cie-+tkhiKiQFaMaz5Oz7uhA@mail.gmail.com> | So it is not EST in the legislation? There are no abbreviations in the legislation. Abbreviations are not needed at all, using them is a mistake. | > It is also (if unimaginative) a rational name, unlike | > "daylight saving" which is gibberish. | I would not call EST a name, Not EST, "Summer Time" which is what it is called. | but more an acronym and it is one used in | the IANA timezone database for Eastern non-DST time as well as DST You keep missing the point, in Aust there is no such thing as DST, there is Summer Time. Eastern Summer Time and Central Summer Time (no Western...) | >(and appropriate here is nothing from the commonwealth govt, | Why? Because the commonwealth govt is not responsible for time in Aust, the states are. Aust was formed as a commonwealth of several independent states, who gave a list of specific powers to the commonwealth govt (defence, international relations, trade ... you can read the Aust constitution if you want a full list - the states can also hand over power for specific issues if they feel inclined) Everything not expressly granted to the commonwealth govt remains the responsibility of the states - which includes what the time is. | > and certainly not the Bureau of Met). | Why? They're an agency of the commonwealth govt (see above) with responsibility for forecasting the weather (and related issues) - if you were to pick a national agency that came closer to responsibility for time it would be the national measurement lab. But they're intelligent enough not to try and step all over state responsibilities. kre
On Mon, Apr 1, 2013, at 10:45, Robert Elz wrote:
You keep missing the point, in Aust there is no such thing as DST, there is Summer Time. Eastern Summer Time and Central Summer Time (no Western...)
Why does everyone call it that, then? http://www.safework.sa.gov.au/show_page.jsp?id=2675 http://www.communityrelations.lawlink.nsw.gov.au/cru/daylight.html http://www.legislation.sa.gov.au/LZ/C/A/DAYLIGHT%20SAVING%20ACT%201971.aspx Also... http://www.legislation.nsw.gov.au/maintop/view/inforce/act+149+1987+cd+0+N Oops, I guess it should be NSWST (for New South Wales Standard/Summer Time), not EST. I'd think that with your insistence on only following state law, that therefore you should support the "abandon the status quo" option along with the rest of us (and then you can support NSWT or NSWST or whatever in the "what now?" vote after) Still one acronym year-round, but at least there wouldn't be any confusion against the timezone described here: http://www.legislation.qld.gov.au/LEGISLTN/CURRENT/S/StandTimeA1894.pdf ...which isn't called Eastern Standard Time either.
On Mon, Apr 1, 2013 at 4:45 PM, Robert Elz <kre@munnari.oz.au> wrote:
Date: Mon, 1 Apr 2013 14:58:27 +0200 From: Tobias Conradi <tobias.conradi@gmail.com> Message-ID: <CAAGevbX_K5E174-F5PVXuytbA4cie-+tkhiKiQFaMaz5Oz7uhA@mail.gmail.com>
I don't think that anybody wants the tz database to use different abbreviations from what is in common use in Australia.
Then why the IANA timezone database contains EST for Daylight saving time in Eastern Australia?
It is "Summer Time" (Eastern Summer Time) which is what it is called in the legislation.
So it is not EST in the legislation?
There are no abbreviations in the legislation. Thanks for the confirmation that your answer didn't relate much to the question why there is EST in the IANA timezone database..
Abbreviations are not needed at all, Timothy showed otherwise.
using them is a mistake. For sure, if the abbreviations are mistakes.
You keep missing the point, in Aust there is no such thing as DST, there is Summer Time. Eastern Summer Time and Central Summer Time (no Western...)
| >(and appropriate here is nothing from the commonwealth govt, | Why?
Because the commonwealth govt is not responsible for time in Aust, Mr. Elz, the thread is not about time in Australia but about acronyms.
| > and certainly not the Bureau of Met). | Why?
They're an agency of the commonwealth govt (see above) with responsibility for forecasting the weather (and related issues) Weather forecasting has been given as a reason by Timothy to have unambiguous acronyms.
- if you were to pick a national agency that came closer to responsibility for time it would be the national measurement lab. What do they have to do with time zone acronyms?
But they're intelligent enough not to try and step all over state responsibilities. It is a states responsibility to define unambiguous acronyms for the Commonwealth?
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
Date: Tue, 2 Apr 2013 00:37:22 +0200 From: Tobias Conradi <tobias.conradi@gmail.com> Message-ID: <CAAGevbU8J8j5PMPDXedegWdNBO+OXSUaFbguSchwTZW=rGyS2Q@mail.gmail.com> | Thanks for the confirmation that your answer didn't relate much to the | question why there is EST in the IANA timezone database.. Because it was reviously answered - they're there because the API requires acronyms. What's more, at the time when the Aust acronyms were chosen (which was well before ado created the tzcode & tzdata) it seemed likely that the acronyms were required to be 3 letters exactly (nothing else had ever been used, and it was unknown what software might be assuming 3 (upper case ascii) letters.) As to why the actual value EST is used, it is because (at least) the Victorian legislation (and it is Victoria where these acronyms were first inserted into unix systems for Aust - that eventually moved them into tzdata) the legislation contains the names "Eastern Standard Time" and "Eastern Summer Time". If you cannot see from that where "EST" comes from (twice) then you (and even more, those who have to care for you on a daily basis) have my sympathy. | > Abbreviations are not needed at all, | Timothy showed otherwise. No, he asserted they were, he showed nothing - for the purposes he claimed to be using them, the acronyms (or any other zone information) are just useless. | > Because the commonwealth govt is not responsible for time in Aust, | Mr. Elz, the thread is not about time in Australia but about acronyms. The comonwealth govt in Aust is not responsible for anything (outside ACT, and perhaps NT) (time, acronyms, what you eat for breakfast ...) unless either the Aust constitution, or some enabling delegation from one of the state governments says it is so. | Weather forecasting has been given as a reason by Timothy to have | unambiguous acronyms. And would you like to explain just how the timezone acronym alters whether it is going to rain or not, or when, or how much (or any other weather event)? | > national measurement lab. | What do they have to do with time zone acronyms? Absolutely nothing, which was the point. But they are the agency that the commonwealth (and the states) defer to for the definitions of various terms and values used for purposes related to all kinds of measurement. They define, in Aust, how long a second is, what "gram" means, ... - if there were to be an existing commonwealth agency that would be likely to have any responsibility for this - other than as it specifically related to ACT or NT - then the NML would most probably be the one that would be selected - just my opinion - but the commonwealth have no power in this area, so no reason to delegate any agency to undertake it, so unless something changes, we will never know. | It is a states responsibility to define unambiguous acronyms for the | Commonwealth? No, it is nobody's responsibility to define unambiguous acronyms for anyone. If you think otherwise, then please explain just where that responsibility originates, and what the penalty is for failing, and who enforces that? (True "responsibility" requires all of that.) The states have no responsibility here (they could, if they wanted, define acronyms for their own time zones, and could make those unambiguous, with respect to other acronyms defined inside their own state, if they wanted, but that's all, and they are certainly not required to do so, and have not). There is no-one else, it certainly is not the commonwealth of Aust's responsibility, they would be acting beyond their powers if they tried (so aside from a few informational web pages, aimed at tourists, which no-one with any knowledge would claim have any authority at all, they don't.) Nor is it our responsibility, we just provide data that meets the requirements of the API, which calls for an acronym to exist, but places very few requirements on what that acronym actually is, and what requirements there are all relate to its syntax, not at all to its value. Now if you're thinking that that would make the acronym useless, and pointless, then you're finally getting it. And no, it is not our job to fix that, the API is defined by POSIX, if you want the definition fixed, go complain to them, not to us. Personally I'd be quite happy (but please do not treat this as a request, or even a serious suggestion, it is not) if we were to set all of the acronyms, in all of the zones (in Aust and all other places) to ZZZ. kre
(Weedwhacker applied to the Cc list.) Robert Elz <kre@munnari.OZ.AU> writes:
Now if you're thinking that that would make the acronym useless, and pointless, then you're finally getting it. And no, it is not our job to fix that, the API is defined by POSIX, if you want the definition fixed, go complain to them, not to us.
I would say that there's no hope, but after decades and innumerable security holes, the ISO C standard seems to have officially killed gets(). Sadly, security is an easier argument than "it's been a bad idea ever since people in more than one country used it," but maybe after another couple of decades someone will manage to kill %Z and tzname. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
On Tue, Apr 2, 2013, at 1:27, Robert Elz wrote:
As to why the actual value EST is used, it is because (at least) the Victorian legislation (and it is Victoria where these acronyms were first inserted into unix systems for Aust - that eventually moved them into tzdata) the legislation contains the names "Eastern Standard Time" and "Eastern Summer Time".
No, it doesn't. ADO just posted a link to it, and the word "Eastern" appears not once within. The time zone has no name. By that measure, we should change it to MELT/MELST.
The comonwealth govt in Aust is not responsible for anything (outside ACT, and perhaps NT) (time, acronyms, what you eat for breakfast ...) unless either the Aust constitution, or some enabling delegation from one of the state governments says it is so.
"Trade and commerce with other countries, and among the States" How to refer to the time zone of one state from another, from outside the country, or how to make a reference (published from witthin one state) to a state's timezone for people in other states or other countries to see, arguably qualifies.
Personally I'd be quite happy (but please do not treat this as a request, or even a serious suggestion, it is not) if we were to set all of the acronyms, in all of the zones (in Aust and all other places) to ZZZ.
Why not set them to "+10:00" [etc], so that %Z can become as useful as %z? There's no fundamental reason people shouldn't be able to print time zone information. And for a portable C program (assuming C11 is not supported), %Z is the only available means to do so. Strictly, there's nothing requiring %Z to be related to tzname, so it could even still do the +10:00 even if tzname has been set to an alphabetic string by parsing a POSIX-style TZ value.
One other factoid: the C language standard calls for various formatting functions to produce "the locale’s time zone name or abbreviation, or by no characters if no time zone is determinable." (Some history: early draft language standards specified "time zone name;" a proposal to change to "time zone abbreviation" was rejected; "name or abbreviation" is where things landed.) @dashdashado On Tue, Apr 2, 2013 at 10:21 AM, <random832@fastmail.us> wrote:
On Tue, Apr 2, 2013, at 1:27, Robert Elz wrote:
As to why the actual value EST is used, it is because (at least) the Victorian legislation (and it is Victoria where these acronyms were first inserted into unix systems for Aust - that eventually moved them into tzdata) the legislation contains the names "Eastern Standard Time" and "Eastern Summer Time".
No, it doesn't. ADO just posted a link to it, and the word "Eastern" appears not once within. The time zone has no name. By that measure, we should change it to MELT/MELST.
The comonwealth govt in Aust is not responsible for anything (outside ACT, and perhaps NT) (time, acronyms, what you eat for breakfast ...) unless either the Aust constitution, or some enabling delegation from one of the state governments says it is so.
"Trade and commerce with other countries, and among the States"
How to refer to the time zone of one state from another, from outside the country, or how to make a reference (published from witthin one state) to a state's timezone for people in other states or other countries to see, arguably qualifies.
Personally I'd be quite happy (but please do not treat this as a request, or even a serious suggestion, it is not) if we were to set all of the acronyms, in all of the zones (in Aust and all other places) to ZZZ.
Why not set them to "+10:00" [etc], so that %Z can become as useful as %z?
There's no fundamental reason people shouldn't be able to print time zone information. And for a portable C program (assuming C11 is not supported), %Z is the only available means to do so.
Strictly, there's nothing requiring %Z to be related to tzname, so it could even still do the +10:00 even if tzname has been set to an alphabetic string by parsing a POSIX-style TZ value.
On Apr 2, 2013, at 8:04 AM, Arthur David Olson <arthurdavidolson@gmail.com> wrote:
One other factoid: the C language standard calls for various formatting functions to produce "the locale’s time zone name or abbreviation, or by no characters if no time zone is determinable."
(Some history: early draft language standards specified "time zone name;" a proposal to change to "time zone abbreviation" was rejected; "name or abbreviation" is where things landed.)
...and the _tzname[] array in the Microsoft Visual C run-time library supplies long names, not abbreviations, as I remember. (How rude a surprise it would be for a UN*X's system library to do so is another matter.)
On Mon, 01 Apr 2013, Tobias Conradi wrote:
If you want change, then it is incumbent on you to demonstrate that your preferred abbreviations are either in wider use than the alternatives, or have more official government backing than the alternatives. Why?
If you don't agree that the person proposing a change should present a good reason for the change, then we have little common ground.
Selective quoting from some web sites does not constitute such a demonstration. How would you demonstrate "official government backing" if not by selecting a subset of official government websites?
Certainly not by selecting only those sources that agree with you. Perhaps by performing a survey of many web sites, whether or not they agree with you, and tabulating the results; if you are right, then the results will show that your side has a clear majority, and most of the objections will go away. --apb (Alan Barrett)
So the issues here is 'common usage' vs Federal government usage vs State government usage. I don't know how we could do a survey, but when it comes to common usage, of course, this could vary by individual, so I believe 'common usage' should be low priority if there are recommended government standards. And if there are differences between state law and federal law, the recommendations of the federal government should trump state government since federal law tries to drive consistancy between states in a federation. The only potential exception is of course if the federal law explicitly states that Australian states must define their own terminology, at which point we need tz regions for each state. So therefore any survey should be based first only on federal government websites and statutes.
On Mon, Apr 1, 2013 at 4:44 PM, David Patte ₯ <dpatte@relativedata.com> wrote:
So the issues here is 'common usage' vs Federal government usage vs State government usage.
Maybe not even that. It is about choosing any set of acronyms that differentiates between different offsets. Common usage, Paul's survey: http://mm.icann.org/pipermail/tz/2012-October/018364.html AEST AEDT CST CDT WST WDT Federal govt http://australia.gov.au/about-australia/our-country/time#daylightsaving AEST AEDT ACST ACDT AWST IANA timezone database ftp://ftp.iana.org/tz/data/australasia EST CST WST No markers for DST at all. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
Based on the below I suggest to add EDT and CDT. It is the minimal change, if counted in quantity of changed letters during DST, to achieve what the thread opener wanted: Acronyms that allow to differentiate between zones that in winter are one and in summer are two. 1) (A)EST and (A)EDT 2) (A)CST and (A)CDT On Tue, Apr 2, 2013 at 12:56 AM, Tobias Conradi <tobias.conradi@gmail.com> wrote:
On Mon, Apr 1, 2013 at 4:44 PM, David Patte ₯ <dpatte@relativedata.com> wrote:
So the issues here is 'common usage' vs Federal government usage vs State government usage.
Maybe not even that. It is about choosing any set of acronyms that differentiates between different offsets.
Common usage, Paul's survey: http://mm.icann.org/pipermail/tz/2012-October/018364.html AEST AEDT CST CDT WST WDT
Federal govt http://australia.gov.au/about-australia/our-country/time#daylightsaving AEST AEDT ACST ACDT AWST
IANA timezone database ftp://ftp.iana.org/tz/data/australasia EST CST WST
No markers for DST at all.
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
I'll let you read this site, and decide whether it should be considered more authoritative than the opinions of those trying to block this change in the tz database. http://australia.gov.au/about-australia/our-country/time#daylightsaving Until then, I suggest that those that would like to see the government recommended abbreviations in their O/Ss and software work together to provide a new patched distro that would override tz in their systems. We could start defining a new database and format immediately, since this issue has been left unresolved too long.
For whatever it's worth, a link to Victoria's "Summer Time Act 1972 No. 8297 of 1972; Version incorporating amendments as at 31 May 2012" is... http://www.legislation.vic.gov.au/Domino/Web_Notes/LDMS/LTObject_Store/LTObj... @dashdashado On Mon, Apr 1, 2013 at 9:46 PM, David Patte ₯ <dpatte@relativedata.com>wrote:
I'll let you read this site, and decide whether it should be considered more authoritative than the opinions of those trying to block this change in the tz database.
http://australia.gov.au/about-**australia/our-country/time#** daylightsaving<http://australia.gov.au/about-australia/our-country/time#daylightsaving>
Until then, I suggest that those that would like to see the government recommended abbreviations in their O/Ss and software work together to provide a new patched distro that would override tz in their systems. We could start defining a new database and format immediately, since this issue has been left unresolved too long.
On Tue, Apr 2, 2013 at 5:34 AM, Arthur David Olson <arthurdavidolson@gmail.com> wrote:
For whatever it's worth, a link to Victoria's "Summer Time Act 1972 No. 8297 of 1972; Version incorporating amendments as at 31 May 2012" is...
http://www.legislation.vic.gov.au/Domino/Web_Notes/LDMS/LTObject_Store/LTObj...
@dashdashado
I wonder what the PDF could be worth in this discussion, since is does not contain any single acronym for a time zone. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
On 04/01/2013 11:42 PM, Tobias Conradi wrote:
On Tue, Apr 2, 2013 at 5:34 AM, Arthur David Olson <arthurdavidolson@gmail.com> wrote:
For whatever it's worth, a link to Victoria's "Summer Time Act 1972 No. 8297 of 1972; Version incorporating amendments as at 31 May 2012" is...
http://www.legislation.vic.gov.au/Domino/Web_Notes/LDMS/LTObject_Store/LTObj...
@dashdashado I wonder what the PDF could be worth in this discussion, since is does not contain any single acronym for a time zone.
Nor the name "Eastern", or indeed any name (at least NSW's says "New South Wales summer time"). Maybe we should just use MELT/MELST. The states don't seem to be, as a rule, interested in specifying how to refer to the timezones from outside of them.
On Mon, Apr 1, 2013 at 3:10 PM, Alan Barrett <apb@cequrux.com> wrote:
On Mon, 01 Apr 2013, Tobias Conradi wrote:
If you want change, then it is incumbent on you to demonstrate that your preferred abbreviations are either in wider use than the alternatives, or have more official government backing than the alternatives.
Why?
If you don't agree that the person proposing a change should present a good reason for the change, I agree with that and Timothy presented a good reason for the change he proposed. Differentiating between Eastern non-DST and Eastern DST time by the acronym.
then we have little common ground. Seems we have some common ground missing anyway, since your requirement is not understandable to me. And you refuse to explain it, when asked "Why?"
Selective quoting from some web sites does not constitute such a demonstration.
How would you demonstrate "official government backing" if not by selecting a subset of official government websites?
Certainly not by selecting only those sources that agree with you.
Perhaps by performing a survey of many web sites, whether or not they agree with you, and tabulating the results; if you are right, then the results will show that your side has a clear majority, and most of the objections will go away. This will fail if there are not "many web sites" showing "official government backing".
That aside, what is "many" for you, so one could start to try to match this requirement? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
On Tue, 02 Apr 2013, Tobias Conradi wrote:
Seems we have some common ground missing anyway, since your requirement is not understandable to me. And you refuse to explain it, when asked "Why?"
I thought that I had explained my position many times, but let me try once more. It does no good to come to the tz project and say "those abbreviations are illogical" or "different abbreviations would be more useful", because the tz project is not in the business of choosing logical or useful abbreviations. The tz project is in the business of documenting existing practice, so if you want the tz project to change its abbreviations then you have to show what the existing practice actually is. If the existing practice is inconsistent, then you have a problem. As I see it, the situation is something like this: (0) A fundamental principle of operation of the tz database is that it does not set policy for timekeeping anywhere; it merely attempts to document existing practice. It is not in the business of choosing useful or logical abbreviations; it is in the business of documenting the abbreviations that are already in use. (1) The tz database has some abbreviations for Australian time zones. (2) Somebody comes along and says "Those abbreviations in (1) are wrong! Here's a link to a government web site (A) that uses different abbreviations." (3) Somebody else says "Oh yeah? Here are links to different government web sites (B) and (C) that disagree with (A)." (4) Somebody else says "Oh yeah? Here's a link to another government web site (D) that agrees with (A)." (5) Somebody says "As long as there's disagreement in Australia, the tz project should make no changes to the abbreviations in (1)." (6) Somebody says "But the web site (A) is an official publication of the central government, and the web site (B) is from some unimportant department." (7) Somebody says "The web site (A) is irrelevant because it is directed at tourists, it's not an official standard of any sort." (8) Somebody says "The web site (A) is irrelevant because the central government has no jurisdiction over time zone names, that power lies with the state governments." etc., ad nauseam. I have left out many steps and paraphrased the comments. As long as different people can point to different web sites that say different things, and there is no overall summary, this matter is unlikely to be resolved. I have no decision making power here, and I have no wish to lay out a set of necessary conditions, but here's a stab at a set of sufficient conditions: Provide a list of what abbreviations are actually in use by the people in Australia, and what abbreviations are legislated or standardised or recommended by governments or industry bodies or interest groups. If there is inconsistency, then present a report on the relative frequency of use of the different abbreviations. If the report shows a clear consensus in favour of one set of abbreviations, then those are the abbreviations that the tz project should use. So far, we have identified that there is inconsistency, but I have no idea which abbreviations are in wider use. --apb (Alan Barrett)
On 02/04/13 09:30, Alan Barrett wrote:
As long as different people can point to different web sites that say different things, and there is no overall summary, this matter is unlikely to be resolved.
I have no decision making power here, and I have no wish to lay out a set of necessary conditions, but here's a stab at a set of sufficient conditions:
Provide a list of what abbreviations are actually in use by the people in Australia, and what abbreviations are legislated or standardised or recommended by governments or industry bodies or interest groups. If there is inconsistency, then present a report on the relative frequency of use of the different abbreviations. If the report shows a clear consensus in favour of one set of abbreviations, then those are the abbreviations that the tz project should use.
So far, we have identified that there is inconsistency, but I have no idea which abbreviations are in wider use.
I suspect that there isn't any consistency. In the UK where we have just one timezone, commonly abbreviated to GMT and BST depending on the time of year, we *still* have problems. I've had people refer to UK time as GMT regardless of the time of year (this is especially confusing around March/April and October/November). The man or woman on the street doesn't care about the abbreviation. Apart from GMT (use and misuse) people usually refer to "summer time" and "winter time", or, around the weekend of the clock change "old time" and "new time". In the US, it seems to be common to refer to ET and PT (Eastern, Pacific). I'm not a US resident, but I've seen TV trailers refer to that quite a few times. I also vividly recall a US manager insisting that the time of a meeting would be 10am PST, just after the switch to PDT. (She insisted that it was Pacific Standard Time all year round.) Most people don't use timezone names beyond "what time is it for Aunty Clara in New Zealand/Canada/far-flung-country-of-choice?" Many of those people that really do car what time is it have multiple timezone clocks that display a city name. I would happily get rid of the abbreviations completely and, if an offset needs to be expressed, use +/-HHMM. jch
The abbreviations only really make sense is where people commonly deal with multiple timezones, such as in broad countries like the US or AU.
(She insisted that it was Pacific Standard Time all year round.)
Yes, a lot of misunderstandings, even in those countries.
if an offset needs to be expressed, use +/-HHMM.
That works for single points in time. It does not, however, handle repeating meetings. For example: Mondays at 8:00 PT You can't really express this with offsets in any way that would be more understandable than the full name. One could try: Mondays at 8:00 GMT-7/8. But nobody is familiar with that: leaving people to guess that you mean -7 most of the year, but -8 from Nov to mid March. Mark <https://plus.google.com/114199149796022210033> * * *— Il meglio è l’inimico del bene —* ** On Tue, Apr 2, 2013 at 11:19 AM, John Haxby <john.haxby@oracle.com> wrote:
On 02/04/13 09:30, Alan Barrett wrote:
As long as different people can point to different web sites that say different things, and there is no overall summary, this matter is unlikely to be resolved.
I have no decision making power here, and I have no wish to lay out a set of necessary conditions, but here's a stab at a set of sufficient conditions:
Provide a list of what abbreviations are actually in use by the people in Australia, and what abbreviations are legislated or standardised or recommended by governments or industry bodies or interest groups. If there is inconsistency, then present a report on the relative frequency of use of the different abbreviations. If the report shows a clear consensus in favour of one set of abbreviations, then those are the abbreviations that the tz project should use.
So far, we have identified that there is inconsistency, but I have no idea which abbreviations are in wider use.
I suspect that there isn't any consistency.
In the UK where we have just one timezone, commonly abbreviated to GMT and BST depending on the time of year, we *still* have problems. I've had people refer to UK time as GMT regardless of the time of year (this is especially confusing around March/April and October/November).
The man or woman on the street doesn't care about the abbreviation. Apart from GMT (use and misuse) people usually refer to "summer time" and "winter time", or, around the weekend of the clock change "old time" and "new time".
In the US, it seems to be common to refer to ET and PT (Eastern, Pacific). I'm not a US resident, but I've seen TV trailers refer to that quite a few times. I also vividly recall a US manager insisting that the time of a meeting would be 10am PST, just after the switch to PDT. (She insisted that it was Pacific Standard Time all year round.)
Most people don't use timezone names beyond "what time is it for Aunty Clara in New Zealand/Canada/far-flung-country-of-choice?" Many of those people that really do car what time is it have multiple timezone clocks that display a city name.
I would happily get rid of the abbreviations completely and, if an offset needs to be expressed, use +/-HHMM.
jch
Mark Davis ☕ <mark@macchiato.com> writes:
That works for single points in time. It does not, however, handle repeating meetings. For example:
Mondays at 8:00 PT
If you're writing calendaring software, generally you switch to using something like the tz identifiers, which give you America/Los_Angeles and well-defined behavior. You *definitely* do not want to use time zone abbreviations for this, since they too would be completely wrong for the same reason! If you schedule a meeting in PDT, you want it to change to PST when daylight saving time ends. Which is the behavior you get from America/Los_Angeles (or some equivalent identifier such as PST8PDT). Humans don't need the abbreviation and don't care. They either schedule the meeting in local time or in the current time in some other time zone (or possibly in UTC) and then just expect the software to cope with changes due to daylight saving time. This is a detail of the calendar exchange format and internal representation, not the user interface. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Russ Allbery said:
That works for single points in time. It does not, however, handle repeating meetings. For example:
Mondays at 8:00 PT
If you're writing calendaring software, generally you switch to using something like the tz identifiers, which give you America/Los_Angeles and well-defined behavior.
You *definitely* do not want to use time zone abbreviations for this, since they too would be completely wrong for the same reason! If you schedule a meeting in PDT, you want it to change to PST when daylight saving time ends. Which is the behavior you get from America/Los_Angeles (or some equivalent identifier such as PST8PDT).
Except, if I understand correctly, the US terminology "PT" (and similarly "ET", "CT", and "MT") means "PST or PDT, whichever is currently in force"). -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
"Clive D.W. Feather" <clive@davros.org> writes:
Russ Allbery said:
You *definitely* do not want to use time zone abbreviations for this, since they too would be completely wrong for the same reason! If you schedule a meeting in PDT, you want it to change to PST when daylight saving time ends. Which is the behavior you get from America/Los_Angeles (or some equivalent identifier such as PST8PDT).
Except, if I understand correctly, the US terminology "PT" (and similarly "ET", "CT", and "MT") means "PST or PDT, whichever is currently in force").
It is common to give times in "Eastern" or "Pacific", which means America/Los_Angeles or America/New_York. "Central" is sometimes used; "Mountain" is relatively rare when giving times (at least in my experience, but I don't live in that zone or near the border of it). It *is* common to refer to "mountain time" or "central time" when talking about time zones informally. Eastern and Pacific are common when giving times because that's how TV schedules are done; many channels run two schedules, one for Eastern and one for Pacific, and people in Central and Mountain just cope and know to add or subtract an hour from posted national times. I don't recall seeing those specific abbreviations as opposed to just the words, but I doubt I would have paid much attention. I bet they're used for things like sports listings for live sporting events. None of this deals with Arizona particularly well. :) I suspect people in Arizona view themselves as switching between Pacific and Mountain depending on the time of the year. Regardless, though, the actual abbreviations used in tzname, etc., aren't useful for giving the times of recurring meetings. TZ identifiers (which include US/Pacific, US/Eastern, etc.) certainly are. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
On Tue, Apr 2, 2013 at 7:50 PM, Russ Allbery <rra@stanford.edu> wrote:
Regardless, though, the actual abbreviations used in tzname, etc., aren't useful for giving the times of recurring meetings. TZ identifiers (which include US/Pacific, US/Eastern, etc.) certainly are.
To programmers, the TZ identifiers are what you want to use. To users, that doesn't work well. What one should supply are the customary names and/or abbreviations, so that users understand them. Mark <https://plus.google.com/114199149796022210033> * * *— Il meglio è l’inimico del bene —* **
Mark Davis ☕ <mark@macchiato.com> writes:
On Tue, Apr 2, 2013 at 7:50 PM, Russ Allbery <rra@stanford.edu> wrote:
Regardless, though, the actual abbreviations used in tzname, etc., aren't useful for giving the times of recurring meetings. TZ identifiers (which include US/Pacific, US/Eastern, etc.) certainly are.
To programmers, the TZ identifiers are what you want to use. To users, that doesn't work well. What one should supply are the customary names and/or abbreviations, so that users understand them.
Sure, this is just an alternate version of the time zone selection problem, which has been much-discussed. But my point is that the specific abbreviations that are put into tzname are worthless for this purpose because they change based on whether it's currently daylight saving time, which is exactly what you don't want for recurring meetings. You don't want to schedule a meeting in PST; at best, that leaves things badly undefined when daylight saving time comes. Does the meeting move or not? In other words, you want some sort of identifier for the time *zone* (whether that be America/Los_Angeles or US/Pacific or PST8PDT or PT or whatever the user understands), not for the current time *offset*. And the latter is what you get from tzname and %Z. If you want to represent the *offset*, that's where numeric identifiers like -0800 are the best approach. As kre says, the time offset abbreviations in tzname, et al., are a bad solution to the wrong problem. (Ironically, the current Australian abbreviations are marginally *more* useful than most of the abbreviations because they *don't* change based on daylight saving time, but of course that's yet another thing people are unhappy about.) I think all the people who are arguing in favor of time offset abbreviations should have the experience I had of writing software that cares greatly about the exact time of things and uses a protocol where using the abbreviations was previously widespread. (In my case, it was writing Usenet software.) After you spend some time dealing with this sort of nonsense: /* Additional non-numeric time zones supported because the old parsedate parser supported them. These aren't legal in RFC 5322, but are supported in lax mode. */ static const struct { const char name[5]; long offset; } OBS_ZONE_OFFSET[] = { { "UTC", 0 }, /* Universal Coordinated */ { "CUT", 0 }, /* Coordinated Universal */ { "WET", 0 }, /* Western European */ { "BST", 1 * 60 * 60 }, /* British Summer */ { "NDT", (-2 * 60 + 30) * 60 }, /* Newfoundland Daylight */ { "NST", (-3 * 60 + 30) * 60 }, /* Newfoundland Standard */ { "ADT", -3 * 60 * 60 }, /* Atlantic Daylight */ { "AST", -4 * 60 * 60 }, /* Atlantic Standard */ { "YDT", -8 * 60 * 60 }, /* Yukon Daylight */ { "YST", -9 * 60 * 60 }, /* Yukon Standard */ { "AKDT", -8 * 60 * 60 }, /* Alaska Daylight */ { "AKST", -9 * 60 * 60 }, /* Alaska Standard */ /* ... */ }; you realize just how obnoxious the abbreviations are, how many cases you're still not handling, why this whole approach is doomed, and why every software that identifies time zone offsets (as opposed to zone names) should just use ISO 8601 and be done with it. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Russ Allbery <rra@stanford.edu> wrote on Tue, 2 Apr 2013 at 11:19:47 -0700 in <87obdwokvw.fsf@windlord.stanford.edu>:
But my point is that the specific abbreviations that are put into tzname are worthless for this purpose because they change based on whether it's currently daylight saving time, which is exactly what you don't want for
They are worthless programatically. But they are handy for humans to look at. Two simple cases: (1) I look at the Date: header and I want to know, without thinking too hard, where the originator is. (2) I can't remember if we are in daylight time or standard time so I type "date" and look at the abbreviation. The current Australian abbrevs do a poor job of both of those cases. Given that they are worthless programatically, any argument that they are based on a dead API, or that programattic consistency is required, etc., etc. is not compelling. If they are worthless to software, let's make them useful to humans, please.
As kre says, the time offset abbreviations in tzname, et al., are a bad solution to the wrong problem.
Sure, but not relevant. We don't have the power to make them go away, and even if we didn't it wouldn't be relevant to our choice of abbrevs. --jhawk@mit.edu John Hawkinson
John Hawkinson <jhawk@MIT.EDU> writes:
(1) I look at the Date: header and I want to know, without thinking too hard, where the originator is.
The Date headers only use ISO 8601 time zone offsets now, and prior to that, even when abbreviations were allowed, you were only permited to use the US time zone abbreviations (or the US military abbreviations, which have tons of other problems and were never in widespread use), never the Australian ones. Or are you referring to a comment in the header? (Your message didn't contain one in your Date header.)
(2) I can't remember if we are in daylight time or standard time so I type "date" and look at the abbreviation.
*heh*. I've done that too, although usually I just look at the time zone offset (via date -R). I think ctime output is ridiculous, so tend to avoid having to look at it.
The current Australian abbrevs do a poor job of both of those cases.
Given that they are worthless programatically, any argument that they are based on a dead API, or that programattic consistency is required, etc., etc. is not compelling. If they are worthless to software, let's make them useful to humans, please.
And this, I think, is the best argument for changing them, and I'm personally mildly inclined to agree, *provided* that it's the last time we ever change them. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Russ Allbery <rra@stanford.edu> wrote on Tue, 2 Apr 2013 at 11:44:22 -0700 in <8738v8ojqx.fsf@windlord.stanford.edu>:
Given that they are worthless programatically, any argument that they are based on a dead API, or that programattic consistency is required, etc., etc. is not compelling. If they are worthless to software, let's make them useful to humans, please.
And this, I think, is the best argument for changing them, and I'm personally mildly inclined to agree, *provided* that it's the last time we ever change them.
Well, I'm just very reluctant to make a firm commitment like that. As I suggested earlier, in the extremely unlikely event that we get an overwhelming outpouring of feedback that the change was wrong (I suggested 10x the comments we had previously received over the past 5 years, compressed into the space of one month), then we would be, I think, churlish to not consider reverting it. Again, I think that is extremely unlikely, but setting a policy that prohibits our reconsidering an error, if it is clear we have made one, would be a mistake. I'd be OK with an advisory commitment though. --jhawk@mit.edu John Hawkinson p.s.: in re Date: headers, ha! Good point. I guess I mean Received: headers, which do seem to have alphabetic abbrevs. But yeah, it's a lot less useful than it used to be. Of course, then there are all these machines that give their time in UTC which I find personally frustrating, not because I have to do arithmetic to figure out the local time (though that's annoying too), but because I have to figure out the offset is...
On Apr 2, 2013, at 2:06 PM, John Hawkinson <jhawk@mit.edu> wrote:
As I suggested earlier, in the extremely unlikely event that we get an overwhelming outpouring of feedback that the change was wrong (I suggested 10x the comments we had previously received over the past 5 years, compressed into the space of one month), then we would be, I think, churlish to not consider reverting it.
And, once we've reverted it, *then* we refuse to change it, unless there's an overwhelming amount of evidence that circumstances have changed and the correct choice of abbreviations is now different. If it turns out that there's going to be a pile of screaming no matter *what* abbreviations are chosen, my inclination would be to replace all controversial abbreviations with the abbreviation for "Standard Time For Users".
Guy Harris <guy@alum.mit.edu> wrote on Tue, 2 Apr 2013 at 14:25:01 -0700 in <CCB6D0C8-8237-41F6-B86B-9BF3B7388D92@alum.mit.edu>:
extremely unlikely event that we get an overwhelming outpouring of ... And, once we've reverted it, *then* we refuse to change it, unless there's an overwhelming amount of evidence that circumstances have changed and the correct choice of abbreviations is now different.
Sounds good to me! --jhawk@mit.edu John Hawkinson
If it turns out that there's going to be a pile of screaming no matter *what* abbreviations are chosen, my inclination would be to replace all controversial abbreviations with the abbreviation for "Standard Time For Users".
sacrificing the moral high ground, you have, sir!
On Apr 2, 2013, at 3:02 PM, John Hawkinson <jhawk@mit.edu> wrote:
Guy Harris <guy@alum.mit.edu> wrote on Tue, 2 Apr 2013 at 14:25:01 -0700 in <CCB6D0C8-8237-41F6-B86B-9BF3B7388D92@alum.mit.edu>:
If it turns out that there's going to be a pile of screaming no matter *what* abbreviations are chosen, my inclination would be to replace all controversial abbreviations with the abbreviation for "Standard Time For Users".
sacrificing the moral high ground, you have, sir!
If you're in a situation where, no matter what you do, there will be somebody passionately arguing against it, there's no moral high ground to be had, so, once you've made your decision, all you can do is stuff cotton in your ears and ignore the complaints. Hopefully, that won't happen here.
On 2 April 2013 16:26, Bennett Todd <bet@rahul.net> wrote:
I betcha there are some thermostats that might get bit, and possibly some medical appliances too.
Or industrial control.
The applications of computers with the most horrific downside risk are, inexplicably, not renowned for the best design expertise at controlling against surprises.
I should sincerely hope that any application capable of receiving tz patches is equally capable of receiving patches that help it handle changes in tz. On 2 April 2013 17:06, John Hawkinson <jhawk@mit.edu> wrote:
I think that is extremely unlikely, but setting a policy that prohibits our reconsidering an error, if it is clear we have made one, would be a mistake.
I'd be OK with an advisory commitment though.
Agreed. Nobody can claim to know all possible use cases that are out there, but we seem to agree that the abbreviations aren't meant to be used by computers anyway. In light of that, it seems quite unlikely that a change to the abbreviations would cause problems (especially if announced well in advance), but we have to allow for the slim chance that it might. -- Tim Parenti
On 3/04/13 05:25 , John Hawkinson wrote:
Russ Allbery <rra@stanford.edu> wrote on Tue, 2 Apr 2013 at 11:19:47 -0700 in <87obdwokvw.fsf@windlord.stanford.edu>:
But my point is that the specific abbreviations that are put into tzname are worthless for this purpose because they change based on whether it's currently daylight saving time, which is exactly what you don't want for They are worthless programatically. But they are handy for humans to look at. Two simple cases:
(1) I look at the Date: header and I want to know, without thinking too hard, where the originator is. You just failed. I'm in Australia, my work Exchange server is in San Francisco. Guess which time you see in my emails if the transport layer is SMTP?
Edwin
On 2 April 2013 13:50, Russ Allbery <rra@stanford.edu> wrote:
Regardless, though, the actual abbreviations used in tzname, etc., aren't useful for giving the times of recurring meetings. TZ identifiers (which include US/Pacific, US/Eastern, etc.) certainly are.
...and therein lies one major issue.
From a programmatic standpoint, absolutely... use the identifiers internally. But for any application that uses multiple zones, the humans using the application need some convenient way to refer to these "zones" in their day-to-day lives. *Note:* I am intentionally ignoring the differences between notions of what "zone" means here; certainly, it can mean different things to (1) us, (2) those not among us who use time zones regularly, and (3) the "layman".
On 2 April 2013 14:03, Alan Mintz <Alan_Mintz+TZ_IANA@earthlink.net> wrote:
Humans don't need the abbreviation and don't care. They either schedule
the meeting in local time or in the current time in some other time zone (or possibly in UTC) and then just expect the software to cope with changes due to daylight saving time. This is a detail of the calendar exchange format and internal representation, not the user interface.
I disagree. I think it's natural to want to abbreviate, especially with things that are repeated a lot.
If I recall correctly, many of those in most vocal opposition to the (A)xST/(A)xDT proposal were the same ones vocally opposed to displaying raw TZ identifiers such as America/New_York to users. Unfortunately, while computers may not need any textual representation for a time zone, the same cannot be said for humans. If not abbreviations, then something else... you can't have it both ways. Arguably, this is the whole reason abbreviations made it into the standard in the first place. Insisting that users say "11:00 Mytown time" for every city or town they might need is absurd, as there are hundreds or thousands of cities and towns in a given "zone", no matter what notion of "zone" you choose. We want our technology to be able to communicate effectively with us, and sensible abbreviations are a completely natural and rational way to facilitate this communication by grouping together common times. On 2 April 2013 14:03, Alan Mintz <Alan_Mintz+TZ_IANA@earthlink.net> wrote:
Like most people, I've lived with the current situation, recognizing that any short TZ abbreviations are potentially ambiguous out of context (i.e. CT can mean US Central time, Central European Time, or Australian Central Time, and probably time in some countries named C*, among others).
Context is everything here. In most communications, it would be reasonably difficult to get CST confused between America/Chicago, Asia/Shanghai, and Australia/Adelaide, because there is generally some additional context about the country being specified. The difficulty lies in disambiguating Australia/Adelaide and Australia/Darwin where, during the summer, the same abbreviation refers to two completely different offsets. I am not making the case for universally unambiguous abbreviations (although that has historically been another proposal), but I don't think it's unreasonable to want these abbreviations *within a single country* not to be so blatantly ambiguous. Shifting the onus to individual admins to write patches or conversion scripts serves as an impediment to the very type of communication (that relating to local times) which this database aims to simplify. Timothy Arceri gave a great example of this. On 2 April 2013 14:03, Mark Davis ☕ <mark@macchiato.com> wrote:
To programmers, the TZ identifiers are what you want to use. To users, that doesn't work well. What one should supply are the customary names and/or abbreviations, so that users understand them.
People on both sides of this argument seem to acknowledge that clear legislation on a federal or multi-state level is practically impossible, so the question comes down to usage. But regardless of what legislation has (or does not have) to say on the subject, let's not lose sight of the fact that *this database serves its users.* Mr Eggert's October 2012 survey clearly showed that (A)xST/(A)xDT is gaining use in Australia. To me, it is not so much a question of if that balance tips, but when. While I agree such usage is currently far from consensus, no one here seems to be disputing the general trend. In addition, while I see much discussion about why we shouldn't worry about abbreviations at all, I see very little about why (A)xST/(A)xDT is substantively worse than xST/xST. One of the few arguments I have seen for maintaining the *status quo*indefinitely is poorly-written legacy code. If that is truly our concern (and I hope it isn't), perhaps we should simply announce such a change well before we actually make it. If we go forward with this change, those users who care about abbreviations will welcome it. Those who don't won't even notice. Perhaps that's the way it should be. -- Tim Parenti
2013-04-02T14:57 tim@timtimeonline.com:
[...] One of the few arguments I have seen for maintaining the status quo indefinitely is poorly-written legacy code. If that is truly our concern (and I hope it isn't), perhaps we should simply announce such a change well before we actually make it.
Very well before. I betcha there are some thermostats that might get bit, and possibly some medical appliances too. Or industrial control. The applications of computers with the most horrific downside risk are, inexplicably, not renowned for the best design expertise at controlling against surprises.
At 2013-04-02 10:08, Russ Allbery wrote:
Mark Davis â <mark@macchiato.com> writes:
That works for single points in time. It does not, however, handle repeating meetings. For example:
Mondays at 8:00 PT
If you're writing calendaring software, generally you switch to using something like the tz identifiers, which give you America/Los_Angeles and well-defined behavior.
Personally, when I write "PT", it's meant as a synonym and abbreviation for the ruleset represented by "America/Los_Angeles". This is meant to be distinct from writing "PST" or "PDT", and used in a context that specifies multiple times that fall both inside and outside the DST offset. However, I also recognize that this distinction is not obvious, and sometimes use the more complex "PST/PDT (UTC-8/7)", which will at least provoke a question if not understood. I don't think enough people outside the OS tech world recognize most of the tz identifiers to use them in this context. *Maybe* with a prefix label like "Time Zone:". Like most people, I've lived with the current situation, recognizing that any short TZ abbreviations are potentially ambiguous out of context (i.e. CT can mean US Central time, Central European Time, or Australian Central Time, and probably time in some countries named C*, among others). I'd like to see promotion by a standards body of an unambiguous format like xxzsT (xx=ISO 3166, Z=intra-country zone abbrev, s={D: DST|S: standard|X:non-specific}), but I don't think just doing it with the tz database framework will be enough to get it recognized unambiguously.
Humans don't need the abbreviation and don't care. They either schedule the meeting in local time or in the current time in some other time zone (or possibly in UTC) and then just expect the software to cope with changes due to daylight saving time. This is a detail of the calendar exchange format and internal representation, not the user interface.
I disagree. I think it's natural to want to abbreviate, especially with things that are repeated a lot. -- Alan Mintz <Alan_Mintz+TZ_IANA@Earthlink.net>
Alan Mintz <Alan_Mintz+TZ_IANA@Earthlink.net> writes:
At 2013-04-02 10:08, Russ Allbery wrote:
Humans don't need the abbreviation and don't care. They either schedule the meeting in local time or in the current time in some other time zone (or possibly in UTC) and then just expect the software to cope with changes due to daylight saving time. This is a detail of the calendar exchange format and internal representation, not the user interface.
I disagree. I think it's natural to want to abbreviate, especially with things that are repeated a lot.
I apologize for phrasing this so badly and creating a bunch of confusion about what I meant. The abbreviations I refer to above are the time offset abbreviations (PDT, PST, etc.), not the abbreviations like PT that actually match a time zone and are therefore arguably more useful. (US/Pacific is just another sort of "abbreviation" in that sense.) That's actually one thing that the current abbreviations for Australia get right; they could be usable for indicating a time zone instead of an offset because they don't change with daylight saving time. But poking around at random web sites in Australia, there's pretty entertaining lack of agreement. For example, http://www.foxsports.com.au/ currently uses both EDT and AEDT in different places on the *same page*, presumably for the same time zone offset (and doesn't use the abbreviation that would stay constant with daylight saving time changes). -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
On 2 April 2013 14:38, Russ Allbery <rra@stanford.edu> wrote:
That's actually one thing that the current abbreviations for Australia get right; they could be usable for indicating a time zone instead of an offset because they don't change with daylight saving time.
Yes, abbreviations that don't change with DST are nice... but only that. Such abbreviations such as ET and PT are used frequently within the United States in advertisements, newspapers, and general communication. The question of "What zone is meant by CT in this context?" is easily answered with America/Chicago. In Australia, the question then becomes, e.g., "What zone is meant by CST in *this* context?" That question is not so easily answered, if it is answerable at all. The case could be made that the user should be more specific, but that defeats the purpose of using the abbreviations in the first place. Arizona in the United States provides an interesting study. While some "laymen" might consider their constant offset to "switch" between the common notion of MT and PT, my (limited) experience with Arizona is that most businesses and news outlets explicitly use the three-letter abbreviation MST. I don't think anyone's applying this argument to Australia (I'm certainly not), but if we did, then Qld should use (A)EST while NSW/ACT/Vic/Tas use (A)ET; NT should use (A)CST while SA uses (A)CT; WA could then simply use (A)WT. There are three issues with that: 1. Abbreviations must be at least three characters to be POSIX-compliant, so the A becomes necessary for consistency. 2. Using ACT to refer to Australian Central Time, which is not the time in the ACT (Australian Capital Territory), would be even more confusing than we have now. 3. Unlike the United States, DST is the exception in Australia, not the rule. So it seems natural to instead emphasize the exception. Arizona does this by being explicit with the S in its abbreviation. Australia can do this by replacing the S with a D when appropriate. This allows the humans using the abbreviations to more easily use them for time conversion. On 2 April 2013 14:25, John Hawkinson <jhawk@mit.edu> wrote:
Two simple cases:
(1) I look at the Date: header and I want to know, without thinking too hard, where the originator is.
(2) I can't remember if we are in daylight time or standard time so I type "date" and look at the abbreviation.
The current Australian abbrevs do a poor job of both of those cases.
I, too, like to be able to get a sense of what a timestamp means without having to first think about what month it is, what season that means it is "down under", which parts of which countries observe DST, and when those DST changes just to determine an offset. For programmatic purposes, this is something computers do wonderfully with the help of tz, but when I get an email on my phone, the last thing I want to do is find a terminal to figure out what "09:00 Sydney time" means for me. On 2 April 2013 14:25, John Hawkinson <jhawk@mit.edu> wrote:
If they are worthless to software, let's make them useful to humans, please.
This is by far the most compelling argument I've seen yet, not just because I happen to agree with it. -- Tim Parenti
Tim Parenti said:
So it seems natural to instead emphasize the exception. Arizona does this by being explicit with the S in its abbreviation. Australia can do this by replacing the S with a D when appropriate.
Please bear in mind that the "D" means nothing to most people in the English-speaking world - "Daylight Saving" is an American construct that is both meaningless and not used by the rest of us. I would actually suggest that the Australian abbreviations be "EST" and "ESuT" if we were going in that direction. (But I'm still in favour of status quo.) -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
"Clive D.W. Feather" <clive@davros.org> writes:
Please bear in mind that the "D" means nothing to most people in the English-speaking world - "Daylight Saving" is an American construct that is both meaningless and not used by the rest of us.
I would actually suggest that the Australian abbreviations be "EST" and "ESuT" if we were going in that direction. (But I'm still in favour of status quo.)
My research this morning poking around Australian TV schedule web sites indicates that some people in Australia are already using EDT or AEDT as time zone abbreviations in sites aimed at the general Australian public. So I suspect that this bridge has already been crossed, and I don't think it's a good idea to introduce yet another new abbreviation that no one is currently using, given that the only point (as well-stated by others) of changing the abbreviations is for human consumption. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
On Tue, Apr 2, 2013, at 15:39, Clive D.W. Feather wrote:
Please bear in mind that the "D" means nothing to most people in the English-speaking world - "Daylight Saving" is an American construct that is both meaningless and not used by the rest of us.
I would actually suggest that the Australian abbreviations be "EST" and "ESuT" if we were going in that direction. (But I'm still in favour of status quo.)
I'll call your attention once again to the fact that despite certain people's protests to the contrary, every state government website calls it that, and the government acts in NSW, Tasmania, and SA, respectively, are called Standard Time Amendment (Daylight Saving) Act 2005, Daylight Saving Act 2007, and the Daylight Saving Act 1971. Even if it doesn't have any "official" standing (but then, neither does "Eastern"), you can't credibly argue it 'means nothing'.
random832@fastmail.us said:
I'll call your attention once again to the fact that despite certain people's protests to the contrary, every state government website calls it that, and the government acts in NSW, Tasmania, and SA, respectively, are called Standard Time Amendment (Daylight Saving) Act 2005, Daylight Saving Act 2007, and the Daylight Saving Act 1971.
Interesting. Thanks.
Even if it doesn't have any "official" standing (but then, neither does "Eastern"), you can't credibly argue it 'means nothing'.
What daylight gets saved? It's a meaningless term. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On Wed, Apr 3, 2013 at 3:56 PM, Clive D.W. Feather <clive@davros.org> wrote:
What daylight gets saved? It's a meaningless term.
The daylight in the early mornings is saved, that is otherwise wasted with few people making use of it. It is a better term anyway than the original 'Seasonal Time-adjustment in Countries South of Lat. 30°' and has stuck in our lexicon since at least 1908. -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/
Clive D.W. Feather <clive@davros.org> wrote on Wed, 3 Apr 2013 at 09:56:20 +0100 in <20130403085620.GC49293@davros.org>:
What daylight gets saved? It's a meaningless term.
No. Clive, you can reasonably argue it is a *nonsensical* term, but not *meaningless*. We know what it means -- a time of hte year when the rules are different in the same geography. I don't think it is too important what the label is, but it is great to use a term that starts with a different letter from the other label, which is all-too-often Standard. (S). --jhawk@mit.edu John Hawkinson
On 2 April 2013 15:39, Clive D.W. Feather <clive@davros.org> wrote:
Please bear in mind that the "D" means nothing to most people in the English-speaking world - "Daylight Saving" is an American construct that is both meaningless and not used by the rest of us.
I would actually suggest that the Australian abbreviations be "EST" and "ESuT" if we were going in that direction. (But I'm still in favour of status quo.)
A very valid point. I'm sure the suggestion of "D" comes about from its current use in many (but certainly not all) English-speaking countries that observe DST and the fact that it's very much different from "S". From that standpoint, "ESuT" is an equally viable (if a bit awkward) abbreviation. However, I'm certain there is *no* documented use of "ESuT" as an abbreviation within Australia; whereas there is at least *some* existing usage of "(A)EDT" et al. Clearly, "the rest of us" who don't use the term "Daylight Saving" excludes at least some Australians. -- Tim Parenti
On 04/02/2013 12:54 PM, Tim Parenti wrote:
I'm certain there is *no* documented use of "ESuT" as an abbreviation within Australia
Sorry, but that's incorrect. "ESuT" is commonly used by the Australian Transport Safety Bureau. This has been discussed on this list before; please see <http://mm.icann.org/pipermail/tz/2001-April/011521.html> and <http://mm.icann.org/pipermail/tz/2010-June/016235.html>. Unfortunately I forgot about ESuT and CSuT when I did my most-recent survey of time zone abbreviation usage in Australia, so we don't have measurements (as imprecise as they are) about how popular these abbreviations are in practice. Some software does support ESuT/CSuT; e.g., see <http://support.novell.com/docs/Tids/Solutions/10051032.html>.
On 2 April 2013 19:02, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 04/02/2013 12:54 PM, Tim Parenti wrote:
I'm certain there is *no* documented use of "ESuT" as an abbreviation within Australia
Sorry, but that's incorrect. "ESuT" is commonly used by the Australian Transport Safety Bureau.
My apologies; that comment was based simply on the strikingly low number of results from a couple quick Google searches. (I admit I didn't really look at the results themselves, as I now see that some ATSB reports using "ESuT" do appear around position #5 for that term in the .au domain.) That said, I actually ran searches on Altavista and Google much like your October 2012 survey, and all of the result counts for "(A)xSuT" on .au sites were at least two full orders of magnitude lower than the corresponding "(A)xDT" abbreviations, in some cases up to four. Strike "no documented use" from my earlier comment and replace it with "little documented use". Further, even the ATSB isn't entirely consistent on their usage. It didn't take much searching to find several accident reports where the time of an incident is given under General Details in "xDT"... not "xSuT" as would be expected: http://www.atsb.gov.au/publications/investigation_reports/2013/rair/ro-2013-... (EDT) http://www.atsb.gov.au/publications/investigation_reports/2011/rair/ro-2011-... (CDT) http://www.atsb.gov.au/publications/investigation_reports/2009/rair/ro-2009-... (WDT) This has been happening since at least the mid-2000s: http://www.atsb.gov.au/publications/investigation_reports/2003/rair/rair2003... (CDT) -- Tim Parenti
On Wed, Apr 3, 2013 at 2:39 AM, Clive D.W. Feather <clive@davros.org> wrote:
Please bear in mind that the "D" means nothing to most people in the English-speaking world - "Daylight Saving" is an American construct that is both meaningless and not used by the rest of us.
I disagree with this. In my experience in Melbourne, the term daylight savings is indeed used. Google backs me up. 305000 hits for melbourne clocks forward ("daylight saving" OR "daylight savings") site:.au 19700 hits for melbourne clocks forward -("daylight saving OR "daylight savings") site:.au The term is used nearly every time we are reminded about upcoming changes. Casual conversation is harder to gauge. I think you "enter daylight savings" but you "are in summer time". -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/
Stuart Bishop said:
Please bear in mind that the "D" means nothing to most people in the English-speaking world - "Daylight Saving" is an American construct that is both meaningless and not used by the rest of us.
I disagree with this. In my experience in Melbourne, the term daylight savings is indeed used.
Okay. My Australian friends said that they didn't use the term, but obviously opinions matter. It's still a meaningless term, though. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On Apr 2, 2013, at 12:39 PM, Clive D.W. Feather <clive@davros.org> wrote:
Please bear in mind that the "D" means nothing to most people in the English-speaking world - "Daylight Saving" is an American construct that is both meaningless and not used by the rest of us.
What term is used by the rest of the English-speaking world? Does the rest of that part of the English-speaking world that adjusts their clocks twice a year turn their clocks forward on or after 21 June or so and turn them backward on or before 21 September or so? If not, they don't keep "summer time", so presumably they have some other term more accurate than "summer time" and more meaningful than "daylight saving time".
"Daylight Saving" is an American construct that is both meaningless and not used by the rest of us.
What term is used by the rest of the English-speaking world?
British English typically uses "summer time" where American English uses "daylight saving time". It's used regardless of what date the clocks are actually advanced or retarted. The term "daylight saving" actually originated in England; the first well-known proposal for daylight saving time was William Willett's in 1907, which called it "daylight saving" rather than "summer" time. In Britain the name was changed to "summer" time as part of the circa-1910 campaign to introduce the practice, and the name change took hold there, as well as in nearby parts of Europe (e.g., "Sommerzeit" in German). Americans stuck with the older name, though.
Guy Harris said:
Please bear in mind that the "D" means nothing to most people in the English-speaking world - "Daylight Saving" is an American construct that is both meaningless and not used by the rest of us.
What term is used by the rest of the English-speaking world?
"Summer Time", as in "British Summer Time".
Does the rest of that part of the English-speaking world that adjusts their clocks twice a year turn their clocks forward on or after 21 June or so and turn them backward on or before 21 September or so? If not, they don't keep "summer time",
You have it wrong. So long as the transition dates are before 22nd June and after 22nd September (in the northern hemisphere), it is the time that applies throughout summer and so is clearly "summer time". -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On Tue, 2 Apr 2013, Alan Mintz wrote:
I disagree. I think it's natural to want to abbreviate, especially with things that are repeated a lot.
But that has to be done in a localized way anyway. In the Netherlands, nobody uses CEST or CET, but rather MEZT and MET... but the tz database doesn't have those either. The localization and naming is done very well in CLDR. I have implemented the Date/Time support (utilizing this database) in PHP, and have given many presentations about the subject. I always hammer in two things: "just" a timestamp is useless, and: never rely or use an abbreviation for anything. cheers, Derick
On Apr 2, 2013, at 3:56 PM, Derick Rethans <tz@derickrethans.nl> wrote:
The localization and naming is done very well in CLDR.
...and, at least from a quick look at common/main/en_AU.xml in version 23 as downloaded from http://cldr.unicode.org, the "metazones" for Australia have: <metazone type="Australia_Central"> <short> <generic>ACT</generic> <standard>ACST</standard> <daylight>ACDT</daylight> </short> </metazone> <metazone type="Australia_CentralWestern"> <short> <generic>ACWT</generic> <standard>ACWST</standard> <daylight>ACWDT</daylight> </short> </metazone> <metazone type="Australia_Eastern"> <short> <generic>AET</generic> <standard>AEST</standard> <daylight>AEDT</daylight> </short> </metazone> <metazone type="Australia_Western"> <short> <generic>AWT</generic> <standard>AWST</standard> <daylight>AWDT</daylight> </short> </metazone>
On 3/04/13 04:08 , Russ Allbery wrote:
Mark Davis ☕ <mark@macchiato.com> writes:
That works for single points in time. It does not, however, handle repeating meetings. For example: Mondays at 8:00 PT If you're writing calendaring software, generally you switch to using something like the tz identifiers, which give you America/Los_Angeles and well-defined behavior. But there is too many crappy software out there which does not support this.
Humans don't need the abbreviation and don't care.
Yes they do, it is much easier because there are less and they can be pictured in the mind. If I say Europe/Madrid and Europe/Lisbon, most people will not realize that they are not in the same timezone. If I say CEST and AZOST, that will ring a bell saying "Hey guys, there is a time difference here". Edwin
On 2013-04-01 6:28, Alan Barrett wrote:
I don't think that anybody wants the tz database to use different abbreviations from what is in common use in Australia.
I think you may be incorrect. What people want is the most popular and usable standard used in Australia that differentiates between standard/winter time and daylight/summer time. Several government pages seem to show that a standard for the eastern zone is AEST/AEDT or EST/EDT, yet the database shows EST/EST, which is both ambiguous and, as far as I can tell, not directly recommended on most modern AU government pages. In this case I dont care for the eastern zone whether AEST/ADST or EST/EDT is used in the database. Either would be better, and less ambiguous than what the database currently uses. And that is the point being made here.
On Mon, 01 Apr 2013, David Patte ₯ wrote:
On 2013-04-01 6:28, Alan Barrett wrote:
I don't think that anybody wants the tz database to use different abbreviations from what is in common use in Australia.
I think you may be incorrect. What people want is the most popular and usable standard used in Australia that differentiates between standard/winter time and daylight/summer time.
I think that the Australian people would be better served by abbreviations that differentiate between standard/winter time and daylight/summer time. But, I think that users of the tz database are better served by abbreviations that follow what Australian people actually use, whether or not those abbreviations are logical, or ambiguous, or differentiate between standard/winter time and daylight/summer time.
Several government pages seem to show that a standard for the eastern zone is AEST/AEDT or EST/EDT, yet the database shows EST/EST, which is both ambiguous and, as far as I can tell, not directly recommended on most modern AU government pages.
In this case I dont care for the eastern zone whether AEST/ADST or EST/EDT is used in the database. Either would be better, and less ambiguous than what the database currently uses. And that is the point being made here.
I was under the impression that "Eastern Summer Time" was the official name used in the relevant state legislation, and that "EST" is the obvious and common abbreviation for that name. If the Australian people really use "EDT" or "AEDT" in preference to "EST" then (a) it would be nice if there was a relatively unbiased survey to demonstrate that, and (b) after the result is demonstrated, but not before, it would be sensible for the tz database to follow suit. --apb (Alan Barrett)
Date: Thu, 28 Mar 2013 02:33:24 +0000 (UTC) From: Timothy Arceri <t.arceri@bom.gov.au> Message-ID: <loom.20130328T025054-507@post.gmane.org> | The issue is not that the identifiers are not unique worldwide. | The problem is that they are not unique to bordering states in the | same country which run along the same time zone. The problem is that you're using those absurd abbreviations at all. Just stop using the things, and all the problems you're having with them will magically go away. We have to keep them, because they're part of the ancient API designed in the US in the early 1970's, a location and time when the things made some (local) sense. The fact that they exist doesn't mean that anyone should use them for anything - and anything we can do to dissuade people from using them, certainly by not doing anything to make the silly things work better is a good thing. If that API had not been invented, we would not have the the things at all. | Most apply daylight savings time, one (Queensland) does not, | this is what causes the confusion. Simply using UTC +10 or UTC +11 | is not good enough as the general public has no idea what UTC is. The general public don't care - they just want to know what time according to the clock on the wall things happen - local time - and that's all you ever need to tell them. | If all states that used EST applied daylight saving then this would be | convenient but as stated above they do not. The problem can be seen in the | delivery example where it would appear an Australian company does | delivery's via time travel. That's a cute example, but anyone and everyone living anywhere in an area where delivery earlier than pickup (apparently) is possible knows that "the clocks the other side of the border are different". People in Coolangatta know that the opening times in Tweed Heads are different (or could be, Tweed Heads probably mostly uses Qld time, I'd guess). You see the exact same effect with airline travel - you leave the east coast of Aust, fly to the west coast of the US (or even a more extreme example, Hawaii) and arrive long before you departed - clock time. The airlines have been dealing with this or a long time now (decades) and they have a system that works, and is understood. Take a look at a flight ticket or itinerary, you'll see that the flight leaves Sydney at 15:30 (or maybe 3:30 pm) and arrives in Los Angeles at 07:30 am (same day). (or whatever). It doesn't say it leaves at 15:30 EST and arrives at 07:30 PDT (or anything like that). Just the time and day. And somewhere it will also note "All times are local". That is, the 15:30 is the time in Sydney when the flight leaves, and the 07:30 is the time in LA when it arrives. No confusion, an amusing time travel experience, and it all just works. | So obviously I'm pushing this for my own reason also. We currently use unix | based systems to produce tsunami arrival times for the Australian Tsunami | Warning System. If you were actually doing what you're suggesting that you're doing then you (or your organisation) ought to be prosecuted for criminal negligence (or something like that). That is, you're suggesting that you're going to tell people that a Tsunami might arrive at 10:45 EST, and that will cause confusion because EST means different things in NSW and Qld. Really! What I wold bet that you will really tell people, is that a Tsunami has is expected and might arrive at Stradbroke Island at 10:30, Byron Bay at 11:38, Noosa at 10:36, Coolangatta at 10:34 Tweed Heads at 11:34 ... That is, the location in Qld, and in NSW is important for this, a Tsunami doesn't arrive (usually) at every point on the coast at the same time. So, what's the timezone abbreviation for? If you tell people in to expect a Tsunami at 10:34, do you really think that anyone is going to wonder what timezone you mean, and perhaps that is 10:34 Perth time??? Or even 10:34 Sydney time? If it is arriving at Coolangatta at 10:34 then it must mean 10:34 local time in Coolangatta. You also tell people it will arrive in Tweed Heads at 11:34 (which in summer is the same absolute time of course). | This information is displayed on a public webpage (and as described above | cannot use UTC convention). The issue comes into play when listing arrival | times for the east coast of Australia, simply listing all arrival times | as EST will obviously cause confusion especially for towns located near | the border of NSW/QLD where it would appear to take a tsunami an extra hour | to arrive only a couple of kilometres away. Do you think that when a Tsunami is imminent anyone is going to be caring about comparing times - the only people who'd ever care are ones who live right there (and so might look up the Coolangatta arrival time even though they're in TWeed Heads, or vice versa - though that's probably a little unlikely, NSW residents would start in the NSW section, and Qld residents there I would think), and the people who live at the border know about the time differences. After the event, when people have time to look at these things and ponder the apparent time anomaly, then they also have time to realise that NSW has summer time, and Qld does not, and that's why there seems to be an hour's difference in the arrival time. | Obviously the ideal solution is to fix the EST/CST abbreviations No, the ideal solution is to stop using them - stop pretending they convey any useful meaning. None of the applications you have mentioned have any business caring about time zone abbreviations (or anything other than "local time at xxx") at all. There are applications that do need to deal with timezones, but the abbreviations are useless to them - if for no other reason than that the lack of any kind of international registry for them means that they cannot help but be ambiguous. You might not care much about the confusion between (Aust) EST and North American EST (and others between the different ISTs and JSTs and ...) but the people for whom timezone management really does matter do. For them, our abbreviations are useless, they either use their own identifying system, or numeric offsets - nothing we do can possibly solve their problems while simultaneously allowing the abbreviations to be used the way you apparently want to use them. kre
On 30 March 2013 22:37, Robert Elz <kre@munnari.oz.au> wrote:
From: Timothy Arceri <t.arceri@bom.gov.au> | The issue is not that the identifiers are not unique worldwide. | The problem is that they are not unique to bordering states in the | same country which run along the same time zone.
The problem is that you're using those absurd abbreviations at all. Just stop using the things, and all the problems you're having with them will magically go away.
[snipped much additional similar comment] I don't comment here much, but I do think that a little more humility towards users is warranted. Its clear from the many discussions over the years that a majority of Australians want this change. Its not one that greatly affects anyone negatively AFAICT. And it clearly does cause some users pain. Whether the pain is of there own making, or whether they shouldn't be doing what they are doing, really is a secondary point. The fact is that they *are* using the data in that way. Unless the tzdb authors want to remove the data in that column entirely, then users are going to continue to use/misuse it. In summary, please make the change, because deliberately inflicting pain on users, even if you disagree with their use cases, just isn't right or fair. Stephen
Though Mr Elz makes a compelling argument for ignoring the abbreviations, it must be accepted that they indeed are part of the data provided in the tz database, and as such we have a responsibility to make that portion of the data as usable as possible. Mr. Arceri's request and explanation makes total sense to me, I totally support his reasoning and agree with him 100%. I recommend that we move forward with Mr Arceri's recommendations as soon as possible. an Mr Arceri's MrOn 2013-03-30 18:37, Robert Elz wrote:
Date: Thu, 28 Mar 2013 02:33:24 +0000 (UTC) From: Timothy Arceri <t.arceri@bom.gov.au> Message-ID: <loom.20130328T025054-507@post.gmane.org>
| The issue is not that the identifiers are not unique worldwide. | The problem is that they are not unique to bordering states in the | same country which run along the same time zone.
The problem is that you're using those absurd abbreviations at all. Just stop using the things, and all the problems you're having with them will magically go away.
We have to keep them, because they're part of the ancient API designed in the US in the early 1970's, a location and time when the things made some (local) sense.
The fact that they exist doesn't mean that anyone should use them for anything - and anything we can do to dissuade people from using them, certainly by not doing anything to make the silly things work better is a good thing.
If that API had not been invented, we would not have the the things at all.
| Most apply daylight savings time, one (Queensland) does not, | this is what causes the confusion. Simply using UTC +10 or UTC +11 | is not good enough as the general public has no idea what UTC is.
The general public don't care - they just want to know what time according to the clock on the wall things happen - local time - and that's all you ever need to tell them.
| If all states that used EST applied daylight saving then this would be | convenient but as stated above they do not. The problem can be seen in the | delivery example where it would appear an Australian company does | delivery's via time travel.
That's a cute example, but anyone and everyone living anywhere in an area where delivery earlier than pickup (apparently) is possible knows that "the clocks the other side of the border are different". People in Coolangatta know that the opening times in Tweed Heads are different (or could be, Tweed Heads probably mostly uses Qld time, I'd guess).
You see the exact same effect with airline travel - you leave the east coast of Aust, fly to the west coast of the US (or even a more extreme example, Hawaii) and arrive long before you departed - clock time. The airlines have been dealing with this or a long time now (decades) and they have a system that works, and is understood. Take a look at a flight ticket or itinerary, you'll see that the flight leaves Sydney at 15:30 (or maybe 3:30 pm) and arrives in Los Angeles at 07:30 am (same day). (or whatever). It doesn't say it leaves at 15:30 EST and arrives at 07:30 PDT (or anything like that). Just the time and day. And somewhere it will also note "All times are local". That is, the 15:30 is the time in Sydney when the flight leaves, and the 07:30 is the time in LA when it arrives.
No confusion, an amusing time travel experience, and it all just works.
| So obviously I'm pushing this for my own reason also. We currently use unix | based systems to produce tsunami arrival times for the Australian Tsunami | Warning System.
If you were actually doing what you're suggesting that you're doing then you (or your organisation) ought to be prosecuted for criminal negligence (or something like that). That is, you're suggesting that you're going to tell people that a Tsunami might arrive at 10:45 EST, and that will cause confusion because EST means different things in NSW and Qld.
Really!
What I wold bet that you will really tell people, is that a Tsunami has is expected and might arrive at Stradbroke Island at 10:30, Byron Bay at 11:38, Noosa at 10:36, Coolangatta at 10:34 Tweed Heads at 11:34 ...
That is, the location in Qld, and in NSW is important for this, a Tsunami doesn't arrive (usually) at every point on the coast at the same time.
So, what's the timezone abbreviation for? If you tell people in to expect a Tsunami at 10:34, do you really think that anyone is going to wonder what timezone you mean, and perhaps that is 10:34 Perth time??? Or even 10:34 Sydney time? If it is arriving at Coolangatta at 10:34 then it must mean 10:34 local time in Coolangatta. You also tell people it will arrive in Tweed Heads at 11:34 (which in summer is the same absolute time of course).
| This information is displayed on a public webpage (and as described above | cannot use UTC convention). The issue comes into play when listing arrival | times for the east coast of Australia, simply listing all arrival times | as EST will obviously cause confusion especially for towns located near | the border of NSW/QLD where it would appear to take a tsunami an extra hour | to arrive only a couple of kilometres away.
Do you think that when a Tsunami is imminent anyone is going to be caring about comparing times - the only people who'd ever care are ones who live right there (and so might look up the Coolangatta arrival time even though they're in TWeed Heads, or vice versa - though that's probably a little unlikely, NSW residents would start in the NSW section, and Qld residents there I would think), and the people who live at the border know about the time differences.
After the event, when people have time to look at these things and ponder the apparent time anomaly, then they also have time to realise that NSW has summer time, and Qld does not, and that's why there seems to be an hour's difference in the arrival time.
| Obviously the ideal solution is to fix the EST/CST abbreviations
No, the ideal solution is to stop using them - stop pretending they convey any useful meaning.
None of the applications you have mentioned have any business caring about time zone abbreviations (or anything other than "local time at xxx") at all.
There are applications that do need to deal with timezones, but the abbreviations are useless to them - if for no other reason than that the lack of any kind of international registry for them means that they cannot help but be ambiguous.
You might not care much about the confusion between (Aust) EST and North American EST (and others between the different ISTs and JSTs and ...) but the people for whom timezone management really does matter do. For them, our abbreviations are useless, they either use their own identifying system, or numeric offsets - nothing we do can possibly solve their problems while simultaneously allowing the abbreviations to be used the way you apparently want to use them.
kre
--
On Sat, Mar 30, 2013, at 18:37, Robert Elz wrote:
The problem is that you're using those absurd abbreviations at all. Just stop using the things, and all the problems you're having with them will magically go away.
I think it is somewhat dishonest to use this as an argument not to change them. If you don't use them, and don't care about them, why do you care about keeping them the same? The API exists. It's not going to go away. We could change what it does entirely - make it print the offset like +09:30, for example. Or do something about localization, since no-one else is going to.
I think it is somewhat dishonest to use this as an argument not to change them. If you don't use them, and don't care about them, why do you care about keeping them the same? ------- Because we don't want to work ourselves to death with constant changes. Someone will complain that we caved and will insist on changing it back to what it was before or someone else will come in and say it was changed the wrong way. Until there is an agreed upon standard there will be no stability; so to not change is the best move. When everybody in Australia comes to an agreement on what those abbreviations should be, let us know. Sincerely, Curtis Manwaring
When everybody in Australia comes to an agreement on what those abbreviations should be, let us know.
What a BS. Distinguishing between /different/ offsets within one country can be done by different sets of abbreviations. If there is forever one Australian X that uses one set and one Australian Y that uses another, then your "requirement" would lead to never have one set provided by the IANA tzdb. Making the DB less usable for any Australian that otherwise would use it to differentiate between any two offsets by the abbreviation. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
I think its quite clear what the most common standard is. AEST / AEDT (and likewise westward) are the national standards. It is also a clear and unambiguous selection for those unfamiliar with local custom, and to the majority of Australians that come to this list. And to finally clarify it and put it everything in perspective, the site from the communityrelations.lawlink says the standards follow the above rules, though "summer time is commonly expressed as EDST". When the approved standard is as in my first line, but a common usage is often "EDST", then you go with the goverment standard, not the common usage. This is not the USA we are talking about here - its Australia, where its citizens tend to somewhat respect the national laws and standards used by the government they have voted for. Are people suggesting we should go with Daylight Saving's' time (which is the 'common expression' in many parts of the USA) when the standard is Daylight Saving (no 's') time? Or worse yet, when some people use one, and some the other - we should then impose a third ambiguous expression upon users of our database, as we are doing now? I'm tired of this debate, as we all are, but clearly the noise can reduced by using the AEST/AEDT (and like) abbreviations over what is defined now. It clearly states on one of the examples presented that the Australian standard is as above but in some calles On 2013-03-30 22:00, Zoidiasoft Technologies wrote:
I think it is somewhat dishonest to use this as an argument not to change them. If you don't use them, and don't care about them, why do you care about keeping them the same?
-------
Because we don't want to work ourselves to death with constant changes. Someone will complain that we caved and will insist on changing it back to what it was before or someone else will come in and say it was changed the wrong way. Until there is an agreed upon standard there will be no stability; so to not change is the best move. When everybody in Australia comes to an agreement on what those abbreviations should be, let us know.
Sincerely, Curtis Manwaring
--
On 30/03/13 22:37, Robert Elz wrote:
Date: Thu, 28 Mar 2013 02:33:24 +0000 (UTC) From: Timothy Arceri <t.arceri@bom.gov.au> Message-ID: <loom.20130328T025054-507@post.gmane.org>
| The issue is not that the identifiers are not unique worldwide. | The problem is that they are not unique to bordering states in the | same country which run along the same time zone.
The problem is that you're using those absurd abbreviations at all. Just stop using the things, and all the problems you're having with them will magically go away.
But they are usefully locally (within a country) for use by humans. Numeric offsets are more appropriate globally and for applications such as email and calendars. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
Hi Timothy, At 19:33 27-03-2013, Timothy Arceri wrote:
It's well past time the Australian abbreviations were updated to reflect the current terms and usage. Stop the confusion and use the abbreviations recommended by the Australian government to try to avoid this mess.
Here are some links on Australian abbreviations. It is difficult for tell what is current usage (e.g. see the first two links). If the Australian government thinks that it is important to stop the confusion it would likely find an effective way to convince the people in Australia about that. I don't think that it is a good idea for the Olson database to dictate what the people within Australian should do. http://www.abc.net.au/4corners/ AEST = Australian Eastern Standard Time http://www.abc.net.au/contact/s3514162.htm Eastern Standard Time (EST) http://www.news.com.au/sport/london-olympics/jamaican-stars-usain-bolt-and-y... AEDT (GMT +11:00) http://www.foxsports.com.au/afl/fixtures All times are listed in EDT http://www.portadelaidefc.com.au/ our live match centre from 12:30pm (CDT) http://www.fantastic-girlguides.com.au/index.php?option=com_content&view=art... - EST (Eastern Australian Standard time) http://www.bom.gov.au/climate/averages/tables/daysavtm.shtml EST - Australian Eastern Standard Time (+10 UTC) in Qld, NSW, Vic and Tas http://www.discovery-carhire.com.au/catalogue/article_australiantime_652.php Eastern-Standard Time (EST) - New South Wales, Victoria, Australian Capital Territory and Queensland. http://services.casa.gov.au/outnback/inc/pages/episode3/episode-3_time_zones... Eastern Standard Time (EST), UTC + 10 hours http://members.iinet.net.au/~jacob/risesetsyd.html EST/EDT (GMT+10 to GMT+11) http://www.studyinaustralia.gov.au/en/Living-in-Australia/Geography/Australi... Central standard time (CST) Regards, -sm
I don't think that it is a good idea for the Olson database to dictate what the people within Australian should do.
What a BS. The DB wouldn't dictate, but would at least offer /one/ set of acronyms that can be used to differentiate between /all/ offsets officially used in Australia for a given point in time. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
On Mar 30, 2013, at 8:53 PM, SM <sm@resistor.net> wrote:
Hi Timothy, At 19:33 27-03-2013, Timothy Arceri wrote:
It's well past time the Australian abbreviations were updated to reflect the current terms and usage. Stop the confusion and use the abbreviations recommended by the Australian government to try to avoid this mess.
Here are some links on Australian abbreviations. It is difficult for tell what is current usage (e.g. see the first two links). If the Australian government thinks that it is important to stop the confusion it would likely find an effective way to convince the people in Australia about that. I don't think that it is a good idea for the Olson database to dictate what the people within Australian should do.
A change in the abbreviation would not change whether the database is dictating what Australians should or will do, so that's not a reason not to change. As a non-Australian, my only interest is in not seeing this debate replayed over and over again. The UN*X APIs already exist and are expected to return time zone abbreviations (some callers might expect it to return three-letter time zone abbreviations, but that's currently not the case even for the US any more), so we're stuck with supplying time zone abbreviations. My vote is to pick the one that the fewest Australians who actually bother to voice an opinion on this dislike, and announce that all subsequent complaints will go to /dev/null (or NUL:, if we get a Windows port :-), so that we won't go through this again.
Guy Harris said:
My vote is to pick the one that the fewest Australians who actually bother to voice an opinion on this dislike,
The problem is that we hear from the ones who want a change. The ones who want the status quo have much less incentive to speak. So if we did change them to a new set, we could well end up getting the same argument again, but this time the CWT etc. people would be complaining and filling up my mailbox while the AEZT people would be saying "there isn't consensus - no need to change it". I don't have a personal stake in this (one reason I deliberatly used mutilated abbreviations) apart from a belief that we need stability. Has anyone tried talking to their MP about this? There must be at least one who would be interested in getting this sorted out, and national legislation [1] *is* the right place to make it authoritative. [1] If this is something delegated to the states, it's still your nation that has to sort it out. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
So if we did change them to a new set, The proposal made by Timothy is not to just change to a /new/ set, but to a set that lets users differentiate between different offsets by the acronym.
we could well end up getting the same argument again, By that reasoning you could oppose any change.
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
Tobias Conradi <tobias.conradi <at> gmail.com> writes:
First off I would like to thank all the people giving me their support on this issue. There have been some very good arguments in support of my suggestion, I'm glad to at least see a good discussion on the problem. I would just like to say I'm yet to see any convincing argument for keeping the status quo vs updating the database. In following post I attempt to address all the arguments against so far. RE: Paul Eggert ----------------
I'm afraid that doesn't follow. One can easily find disagreements with the contents of those links. For example, you gave a link to the NSW Dept of Attorney General & Justice saying that in summer, eastern time is abbreviated "AEDT". But that very web page also says, in another place, that the abbreviation is "EDST". So this single source contradicts the assertion that abbreviations are consistently used by the NSW government. No ii says “Daylight saving or summer time is commonly expressed as EDST”. My name is commonly expressed as Tim Arceri. But my name is Timothy Arceri. It clearly uses AEST/AEDT as the correct abbreviations.
RE: Robert Elz ---------------
The general public don't care - they just want to know what time according to the clock on the wall things happen - local time - and that's all you ever need to tell them.
This is a simplistic and naive view especially when daylight savings is involved as the clock on the wall is not always correct. For example not everyone remembers to update their clock on the change over of daylight savings time. With an emergency warning systems its our job to be as precise as possible as to remove any potential confusion. Another example is a person in NSW ringing up their family in QLD during daylight savings to warn them of a tsunami. They may look at the time of arrival for a QLD location and tell their family that they have 2 hours before the tsunami arrives but in fact it is only 1 hour as they forgot to apply the daylight savings difference. Yes they may forget anyway but by using EST/EDT we have at least given them all the information they need.
If you were actually doing what you're suggesting that you're doing then you (or your organisation) ought to be prosecuted for criminal negligence (or something like that). That is, you're suggesting that you're going to tell people that a Tsunami might arrive at 10:45 EST, and that will cause confusion because EST means different things in NSW and Qld.
Please read things properly before insulting someone I clearly said we need a custom script to make EST/EDT abbreviations. Your argument above actually supports the updating of abbreviations.
You might not care much about the confusion between (Aust) EST and North American EST (and others between the different ISTs and JSTs and ...) but the people for whom timezone management really does matter do. For them, our abbreviations are useless, they either use their own identifying system, or numeric offsets - nothing we do can possibly solve their problems while simultaneously allowing the abbreviations to be used the way you apparently want to use them.
In your whole post you have mentioned not a single reason why its better to keep the current abbreviations rather than updating them with my suggestions (unless you count the fact you wish people didn't use them, but they do). But you have yourself mentioned twice how the current abbreviations cause confusion. RE: Curtis Manwaring ----------------------
Because we don't want to work ourselves to death with constant changes. Someone will complain that we caved and will insist on changing it back to what it was before or someone else will come in and say it was changed the wrong way. Until there is an agreed upon standard there will be no stability; so to not change is the best move. When everybody in Australia comes to an agreement on what those abbreviations should be, let us know. As I've already mentioned the current abbreviation used by the database EST (Eastern Summer Time) is used by no one in Australia all I'm asking is that you at least use something that is recognised and I think I've made a fairly decent attempt are proving there are generally accepted abbreviations used by the state governments. Or as was very well put by David Patte: I think its quite clear what the most common standard is. AEST / AEDT (and likewise westward) are the national standards. It is also a clear and unambiguous selection for those unfamiliar with local custom, and to the majority of Australians that come to this list.
And to finally clarify it and put it everything in perspective, the site from the communityrelations.lawlink says the standards follow the above rules, though "summer time is commonly expressed as EDST".
When the approved standard is as in my first line, but a common usage is often "EDST", then you go with the goverment standard, not the common usage. This is not the USA we are talking about here - its Australia, where its citizens tend to somewhat respect the national laws and standards used by the government they have voted for.
Are people suggesting we should go with Daylight Saving's' time (which is the 'common expression' in many parts of the USA) when the standard is Daylight Saving (no 's') time? Or worse yet, when some people use one, and some the other - we should then impose a third ambiguous expression upon users of our database, as we are doing now?
I'm tired of this debate, as we all are, but clearly the noise can reduced by using the AEST/AEDT (and like) abbreviations over what is defined now.
It clearly states on one of the examples presented that the Australian standard is as above but in some calles RE: SM
It is difficult for tell what is current usage (e.g. see the first two links). If the Australian government thinks that it is important to stop the confusion it would likely find an effective way to convince the people in Australia about that. I don't think that it is a good idea for the Olson database to dictate what the people within Australian should do. Every link you have posted uses the daylight savings abbreviations I'm asking for. Yes the use of a beginning A is seen as somewhat optional (but I don't think anyone would have any objections to its use ) but the daylight savings use of D is consistent. As mentioned above the Olson database is already dictating we use EST (Eastern Summer Time) when no one in Australia does. RE: Clive D.W. Feather
So if we did change them to a new set, we could well end up getting the same argument again, but this time the CWT etc. people would be complaining and filling up my mailbox while the AEZT people would be saying "there isn't consensus - no need to change it".
CWT - Is a separate time zone and is separate issue to the change I'm suggesting . I'm not sure if that database currently supports it but I believe it does not in which case there is no reason they would not be filling up your mailbox anyway. If it is supported then it can possibly be left as is even with the suggested changes although as far as I'm aware this is an unofficial time zone. AEZT – What is this? Also as Tobias Conradi pointed out:
The proposal made by Timothy is not to just change to a /new/ set, but to a set that lets users differentiate between different offsets by the acronym.
On 03/31/2013 04:16 AM, Timothy Arceri wrote:
No ii says “Daylight saving or summer time is commonly expressed as EDST”.
This is splitting hairs, surely. That page uses two different abbreviations, AEDT and EDST, for the same notion. It doesn't say that one abbreviation is preferable to the other. And this is just one example. One can easily find other government sources that disagree with the abbreviations you're suggesting. For example, your own organization's page on daylight saving time <http://www.bom.gov.au/climate/averages/tables/daysavtm.shtml> says that summer time in eastern Australia is generally denoted "EDT", not "AEDT". We shouldn't try to address this problem by choosing a preferred set of abbreviations and then finding web pages agreeing with our preferences. Instead, we should choose what Australians by and large use in practice. Unfortunately, when I recently tried to do that <http://mm.icann.org/pipermail/tz/2012-October/018364.html> I found that the practice seems to be inconsistent: that is, in some regions Australians seem to prefer one set of abbreviations, while in other regions they seem to prefer a different set.
On Mon, Apr 1, 2013 at 10:32 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 03/31/2013 04:16 AM, Timothy Arceri wrote:
No ii says “Daylight saving or summer time is commonly expressed as EDST”.
This is splitting hairs, surely. And surely, I wonder why a bug, if it is one, in page in the www should stop fixing a bug in the IANA timezone database?
That page uses two different abbreviations, AEDT and EDST, for the same notion. It doesn't say that one abbreviation is preferable to the other. And the IANA timezone database uses one acronym for two zones - it doesn't even have /one/ to unambiguously indicate /D/aylight saving /T/ime in /E/astern /A/ustralia.
Both of the above make clever use of the letters E, D and T to indicate Daylight saving Time in the East. Two choices, each an example of how to construct an unambiguous acronym within the context of Australia. And then there is Paul's choice: ambiguous.
And this is just one example. One can easily find other government sources that disagree with the abbreviations you're suggesting. Does that matter? I mean, one can also find lot's of sources that disagree with the Paul-IANA-acronym.
For example, your own organization's page on daylight saving time <http://www.bom.gov.au/climate/averages/tables/daysavtm.shtml> says that summer time in eastern Australia is generally denoted "EDT", not "AEDT". Timothy said it several times, that he regards the A as optional and does not care about it. Maybe as background information for you: /A/ stands for Australia or Australian. So if one assumes a given time notation refers to a time in Australia, then the /A/ does not yield any extra information.
EDT and AEDT are two examples for unambiguous acronyms. Nothing Paul's choice compete with if unambiguosness is the goal. What is the goal of Paul by using EST?
We shouldn't try to address this problem by choosing a preferred set of abbreviations and then finding web pages agreeing with our preferences. Why not?
Instead, we should choose what Australians by and large use in practice. Curious, is that the Paul acronym?
Unfortunately, when I recently tried to do that <http://mm.icann.org/pipermail/tz/2012-October/018364.html> I found that the practice seems to be inconsistent: that is, in some regions Australians seem to prefer one set of abbreviations, while in other regions they seem to prefer a different set. Well, your summary of the the then current situation was:
AEST AEDT CST CDT WST WDT No EST for Daylight saving Time in Eastern Australia, correct? So, why was EST not removed from the IANA timezone database as an acronym for DST by the IANA timezone database maintainer in October 2012? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
Paul Eggert <eggert <at> cs.ucla.edu> writes:
Despite every man and his dog giving requirements for what needs to be proven for this change to be made it seems like Paul Eggert is the only one who can tell me for sure what the requirements for change are. I have already been accused of cherry picking government websites. When in fact all I did was point out the timezone information located on each state government website. Then for the couple that didn’t have a dedicated page with that information I searched the website for a timezone abbreviations. I chose to locate these webpages not as a cherry picking exercise but due to the objections to the use of the timezones on the Australian government website, where it was argued that it was an individual state issue.
Paul Eggert:
“ No ii says “Daylight saving or summer time is commonly expressed as EDST”.
This is splitting hairs, surely. That page uses two different abbreviations, AEDT and EDST, for the same notion. It doesn't say that one abbreviation is preferable to the other.”
No this is not splitting hairs. Yes I agree it could have been worded a little bit clearer but it is obvious to anyone that is not arguing against having to change the Olson database that EDST is just provided as a reference for those who have come across this abbreviation somewhere else. The Northern Territory website does a better job of making the point that the abbreviation on the Australian government website are preferred while still providing the other common expression as a reference. “The Time Zone in the Northern Territory is Australian Central Standard Time (ACST, also commonly referred to as CST).” - http://alicesprings.nt.gov.au/alice-springs/timezone Regardless you have ignored the fact that none of them use EST abbreviation for daylight savings as is used currently in the database.
Paul Eggert:
“We shouldn't try to address this problem by choosing a preferred set of abbreviations and then finding web pages agreeing with our preferences. Instead, we should choose what Australians by and large use in practice. Unfortunately, when I recently tried to do that <http://mm.icann.org/pipermail/tz/2012-October/018364.html> I found that the practice seems to be inconsistent: that is, in some regions Australians seem to prefer one set of abbreviations, while in other regions they seem to prefer a different set.”
Again this does not address my main concern that regardless if states are using AEST/AEDT vs EST/EDT that EST is not commonly used as abbreviation to denote daylight savings time. I would also like to point out some major flaws is your use of searches to gauge what Australians prefer to use rather than using the suggestions of the Australian government or its state governments. Flaws: 1. A large number of the timezone abbreviations used in webpages are placed there using an automated process, such as page last updated times. On a Unix based server where customisations have not been made to output AEST, etc you are going to be getting the abbreviations from this very database. 2. Searching for three letter abbreviations is going to bring back a far greater amount of false positives. All you need to do is look at the first couple of pages of google results to see how bad this is. For example search for "WST" site:.au On the very first page half the result are for Workplace Standards Tasmania (WST). On page two there is only two result that are related to timezones, there results for water meters, the west tigers (WST) national rugby team and stock market codes further pages continue with the same false positives. The results for CST, and EST also show similar false positives with both first pages not returning a single result to do with timezones. On the other hand the four letter abbreviations do return some false positive but to a far lesser extent. If you take the ratio of the false positives into account it starts to make your results from last October look much more favourable on the Australian Government defined abbreviations.
Tobias Conradi <tobias.conradi@gmail.com> writes:
we could well end up getting the same argument again,
By that reasoning you could oppose any change.
Indeed, which is exactly the point. Standards are the most useful when they don't change. I don't particularly care if these abbreviations change, but it's the same problem as with the naming of Chinese time zone names: there is a cost to change. Despite it being a horrible idea, I'm sure some software out there has made assumptions about what abbreviations to expect and will break if the abbreviations change. Avoiding unnecessary change in low-level standard software like the tz database is important; it's hard to know what assumptions have been layered on top of it, given how ubiquitous it is. If the abbreviations do change, I agree with Guy: this should be the last time they ever change short of national legislation clearly and unambiguously establishing different abbreviations. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
On Sun, Mar 31, 2013 at 8:12 PM, Russ Allbery <rra@stanford.edu> wrote:
Tobias Conradi <tobias.conradi@gmail.com> writes: [So if we did change them to a new set,]
we could well end up getting the same argument again,
By that reasoning you could oppose any change.
Indeed, which is exactly the point. I wonder how likely the "same argument" is, if the base for the argument has changed.
And how likely it is to get the "same argument" if the base did not change.
Standards are the most useful when they don't change. A set of acronyms as a standard?
I would like to see who would use the "most useful set/standard" in case the number of real world zones per country grows. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
On Mar 31, 2013, at 12:28 AM, "Clive D.W. Feather" <clive@davros.org> wrote:
Guy Harris said:
My vote is to pick the one that the fewest Australians who actually bother to voice an opinion on this dislike,
The problem is that we hear from the ones who want a change. The ones who want the status quo have much less incentive to speak.
Then perhaps we need to give them an incentive to speak, such as...
So if we did change them to a new set, we could well end up getting the same argument again, but this time the CWT etc. people would be complaining and filling up my mailbox while the AEZT people would be saying "there isn't consensus - no need to change it".
..."this is the last change we will make, so speak now or forever hold your peace, as all subsequent complaints will receive a reply saying 'we already decided this, and we are *NOT* going to reconsider our decision, so you're wasting your time and ours.'"
Guy Harris <guy@alum.mit.edu> wrote on Sun, 31 Mar 2013 at 01:29:20 -0700 in <229CCDC4-FE7E-4175-820A-D125AFF437D3@alum.mit.edu>:
Then perhaps we need to give them an incentive to speak, such as... ... ..."this is the last change we will make, so speak now or forever
We have spent more time debating the possible ramifications of a change than we are likely to receive complaints about the change. It would be foolish to foreclose future changes. If, for instance, we received 10x as much feedback on the change in 1 month as we have received over this issue as debated in the past 5 years, then we should reasonable consider reverting. Forcelosing that would be unwise. At this point I do think we are being silly and reactionary. IMO, we should make the change, clearly articulate the reasons, and see what happens. I suspect we will get very few complaints. (Perhaps someone in favor of the change would like to draft a bulletproof summary of the situation and the justification for making the change. That could be circulated along with the tzdata update that implements the change.) --jhawk@mit.edu John Hawkinson
participants (28)
-
Alan Barrett -
Alan Mintz -
Andrew Paprocki -
Arthur David Olson -
Bennett Todd -
Clive D.W. Feather -
David Patte ₯ -
Derick Rethans -
Edwin Groothuis -
Guy Harris -
Ian Abbott -
John Hawkinson -
John Haxby -
Mark Davis ☕ -
Norbert Lindenberg -
Paul Eggert -
Paul_Koning＠Dell.com -
Random832 -
random832＠fastmail.us
-
Robert Elz -
Russ Allbery -
SM -
Stephen Colebourne -
Stuart Bishop -
Tim Parenti -
Timothy Arceri -
Tobias Conradi -
Zoidiasoft Technologies