Re: [tz] [PATCH 0/2] Follow Australian common usage and update CST/CST to CST/CDT and EST/EST to EST/EDT etc [SEC=UNCLASSIFIED]
I would like to offer (again) the following evidence in support of Timothy's request for a patch to eliminate the ambiguous time zone abbreviations from the TZ Database. The assertion from John Mackin that "We in Australia have _never_ referred to DST as `daylight' time." is patently untrue - the video from four corners (posted previously - see below) is clear evidence that the term is used and has been in use since well before John Mackin's statement from 1991. Language is a living thing it changes and evolves over time so it is possible that in 1991 "summer time" was in vogue. It is also possible that John Mackin comes from the culture of British migrants that may well have used this term due to their British heritage. Either way the Google searches of government web sites show that the phrase "daylight saving" is used, formally, more frequently then "summer time". There are many problems with searching the broader context of .au web sites for frequency of use of "EST" vs. "EDT" and "summer time" vs. "daylight saving": "EST" vs. "EDT" Only tree of the four states in the "Eastern Standard Timezone" have daylight savings and they only have it for aprox. four of the twelve months in the year. And as someone pointed out before many web sites unwittingly use the TZ Database data to automatically timestamp pages. So the frequency of use of "EST" is destined to be much higher then "EDT" and therefore the search is meaningless. "summer time" vs. "daylight saving" "daylight saving" has, pretty much, one unambiguous meaning where as "summer time" (summertime) has so many that have nothing what so ever to do with "daylight saving": - "Summertime" is an aria composed by George Gershwin for the 1935 opera Porgy and Bess. - Summertime is a 1955 American/British Technicolor drama film directed by David Lean - May refer to "British summer time"; given Australia's long association with the mother country old newspapers etc. online often refer to "British summer time" - It may refer to (as it does in many countries) the *seasonal* time of summer as in "summer time and the living is easy". As evidence of this I searched Trove (the National Library of Australia's online collection of digitised Newspapers etc.) <http://trove.nla.gov.au> for these phrases separately "EST", "EDT", "summer time" and "daylight saving". I searched only Australian content and only the Digitised newspapers section, the results were as follows: "EST" = 2,049,093 "EDT" = 27,401 "Summer time" = 55,120 "daylight saving" = 11,960 The only one of these which returns relatively unambiguous results is "daylight saving" and here is why: The first full page of the search for "EST" does not contain a single reference to time. "EST" (Est.) is a very commonly used abbreviation for Established for one thing. "EDT" is just as ambiguous. "daylight saving", is much less ambiguous all-though searching for it will return the likes of "Nothing but fair weather and daylight saved". The earliest use of the term (we never use) is in 1908 referring to the "Daylight Saving Bill" it is referred to in more than a dozen daily newspapers of the time. "Mr. Robert Pearce, tbe member for the Leek division of Staffordshire, is a humorist. To the intense amusement of the House the other day he gravely introducedva measure called the "Daylight_ Saving Bill," by which he proposes, bv an ingenious juggling with' the hoursof the clock, to actually give us more daylight! Mr. Pcarce's project is on the first four Sundays in April to put on the clock 20 minutes between 2 a.m. and 3 p.m., each hour, therefore consisting of only 40 minutes. Similarly it is propo^d in September that the same hour in the morning should consist of 80 minutes. The annual gain of daylight Mr. Pearce esti-mates at 210 hours." [sic.] "Summer time" very rarely refers to Australian "daylight saving time" as can be seen from a selection of results from the first page of the search... ----- Sunday Times (Perth, WA : 1902 - 1954) Sunday 2 November 1947 p 2 Article ... Summertime LONDON, Sat: British summertime time ends tomorrow, when G.M.T. will be restored. Change officially occurs at 3.30 a.m. ----- The Daily News (Perth, WA : 1882 - 1950) Saturday 22 August 1936 Edition: GOLDFIELDS EDITION p 16 Article ... Summertime Summertime is coming near; I heard a blowfly yesterday. Mosquitoes buzzing here and there Are signs that summer's on the way. People talk about the flowers In bloom, and skies of azure blue. I can tell that winter's hours Are few another way, can't you? Winter jumpers are not seen So ... ----- Examiner (Launceston, Tas. : 1900 - 1954) Saturday 24 February 1917 Edition: DAILY p 7 Article ... SUMMER TIME. It is understood that the Government will introduce summer time to operate between April 8 and September 23. ... ----- Oh. Before you jump on that last one look at the dates then realise that it was in a section of the paper headed "British Parliament." In conclusion there is little real unambiguous evidence out there that prooves "summer time" is more commonly used in Australia *to refer to* "Daylight Saving(s) Time" than the phrase "Daylight Saving(s) Time". In actual fact there is more evidence to prove the oposite. Formally the majority of Australian government websites refer to "Daylight Saving(s) Time" and this is the part of the TZ Database that we Australian users disagree with and wish to have changed. ----- search: legislation "standard time" "daylight saving" site:.gov.au About 25,600 results (0.21 seconds) search: legislation "standard time" "summer time" site:.gov.au About 15,600 results (0.14 seconds) N.B. ".gov.au" searches all state and federal official sites as they all use this domain. (e.g. Federal = just .gov.au, State i.e. Victoria = .vic.gov.au ). ----- An interesting video from the 1970's Four Corners program on the ABC (Australia's national broadcaster, ICYDK) on the introduction of "Daylight Saving" in Tasmania. Note the consistent use of that term "Daylight Saving", "Summer Time" is never mentioned (FYI It's a predominantly British term) and take a look at the flight attendant's bonnet! http://www.abc.net.au/archives/80days/stories/2012/01/19/3415208.htm Regards, Peter Stagg Web Developer - Radar Systems, AMDIS, +61 3 9669-4232, www.bom.gov.au ----- Date: Thu, 11 Apr 2013 09:50:04 +1000 From: Timothy Arceri <T.Arceri@bom.gov.au> Subject: [tz] [PATCH 0/2] Follow Australian common usage and update CST/CST to CST/CDT and EST/EST to EST/EDT etc [SEC=UNCLASSIFIED] To: "'tz@iana.org' (tz@iana.org)" <tz@iana.org> Message-ID: <7F491A8A71010C4E8B0266E3478C047A0220B1760322@BOM-VMBX-HO.bom.gov.au> Content-Type: text/plain; charset="us-ascii" <delitia> The reason for the current situation is documented in the Australasia data file:
From John Mackin (1991-03-06): "We in Australia have _never_ referred to DST as `daylight' time. It is called `summer' time. Now by a happy coincidence, `summer' and `standard' happen to start with the same letter; hence, the abbreviation does _not_ change..."
Peter, brings up a great point here about culture. Which can actually be used to explain why we as Australians are happy to use phrase like 'Daylight time' which has been pointed out does not make a lot of sense without its implied association to 'Daylight Savings Time' Anyone that has travelled to Australia will have noticed our affinity to abbreviate just about any word or phrase. A humorous example of this can be seen here: http://www.theprofessionalhobo.com/2009/07/australian-abbreviations/ The extent of this can be seen with the fast food chain McDonalds that has an internationally recognised trademark (McDonalds) that they have spent (I'm guessing) multi millions of dollars advertising and building an image calling itself Maccas rather than McDonalds in recent advertising campaigns. So it's only natural in a country that has an urge to abbreviate and shorten everything that something like EDST (Eastern Daylight Savings Time) as seen on the NSW government website would be shorted to EDT. Tim -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Peter Stagg Sent: Thursday, 11 April 2013 12:04 PM To: 'tz@iana.org' Subject: Re: [tz] [PATCH 0/2] Follow Australian common usage and update CST/CST to CST/CDT and EST/EST to EST/EDT etc [SEC=UNCLASSIFIED] I would like to offer (again) the following evidence in support of Timothy's request for a patch to eliminate the ambiguous time zone abbreviations from the TZ Database. The assertion from John Mackin that "We in Australia have _never_ referred to DST as `daylight' time." is patently untrue - the video from four corners (posted previously - see below) is clear evidence that the term is used and has been in use since well before John Mackin's statement from 1991. Language is a living thing it changes and evolves over time so it is possible that in 1991 "summer time" was in vogue. It is also possible that John Mackin comes from the culture of British migrants that may well have used this term due to their British heritage. Either way the Google searches of government web sites show that the phrase "daylight saving" is used, formally, more frequently then "summer time". There are many problems with searching the broader context of .au web sites for frequency of use of "EST" vs. "EDT" and "summer time" vs. "daylight saving": "EST" vs. "EDT" Only tree of the four states in the "Eastern Standard Timezone" have daylight savings and they only have it for aprox. four of the twelve months in the year. And as someone pointed out before many web sites unwittingly use the TZ Database data to automatically timestamp pages. So the frequency of use of "EST" is destined to be much higher then "EDT" and therefore the search is meaningless. "summer time" vs. "daylight saving" "daylight saving" has, pretty much, one unambiguous meaning where as "summer time" (summertime) has so many that have nothing what so ever to do with "daylight saving": - "Summertime" is an aria composed by George Gershwin for the 1935 opera Porgy and Bess. - Summertime is a 1955 American/British Technicolor drama film directed by David Lean - May refer to "British summer time"; given Australia's long association with the mother country old newspapers etc. online often refer to "British summer time" - It may refer to (as it does in many countries) the *seasonal* time of summer as in "summer time and the living is easy". As evidence of this I searched Trove (the National Library of Australia's online collection of digitised Newspapers etc.) <http://trove.nla.gov.au> for these phrases separately "EST", "EDT", "summer time" and "daylight saving". I searched only Australian content and only the Digitised newspapers section, the results were as follows: "EST" = 2,049,093 "EDT" = 27,401 "Summer time" = 55,120 "daylight saving" = 11,960 The only one of these which returns relatively unambiguous results is "daylight saving" and here is why: The first full page of the search for "EST" does not contain a single reference to time. "EST" (Est.) is a very commonly used abbreviation for Established for one thing. "EDT" is just as ambiguous. "daylight saving", is much less ambiguous all-though searching for it will return the likes of "Nothing but fair weather and daylight saved". The earliest use of the term (we never use) is in 1908 referring to the "Daylight Saving Bill" it is referred to in more than a dozen daily newspapers of the time. "Mr. Robert Pearce, tbe member for the Leek division of Staffordshire, is a humorist. To the intense amusement of the House the other day he gravely introducedva measure called the "Daylight_ Saving Bill," by which he proposes, bv an ingenious juggling with' the hoursof the clock, to actually give us more daylight! Mr. Pcarce's project is on the first four Sundays in April to put on the clock 20 minutes between 2 a.m. and 3 p.m., each hour, therefore consisting of only 40 minutes. Similarly it is propo^d in September that the same hour in the morning should consist of 80 minutes. The annual gain of daylight Mr. Pearce esti-mates at 210 hours." [sic.] "Summer time" very rarely refers to Australian "daylight saving time" as can be seen from a selection of results from the first page of the search... ----- Sunday Times (Perth, WA : 1902 - 1954) Sunday 2 November 1947 p 2 Article ... Summertime LONDON, Sat: British summertime time ends tomorrow, when G.M.T. will be restored. Change officially occurs at 3.30 a.m. ----- The Daily News (Perth, WA : 1882 - 1950) Saturday 22 August 1936 Edition: GOLDFIELDS EDITION p 16 Article ... Summertime Summertime is coming near; I heard a blowfly yesterday. Mosquitoes buzzing here and there Are signs that summer's on the way. People talk about the flowers In bloom, and skies of azure blue. I can tell that winter's hours Are few another way, can't you? Winter jumpers are not seen So ... ----- Examiner (Launceston, Tas. : 1900 - 1954) Saturday 24 February 1917 Edition: DAILY p 7 Article ... SUMMER TIME. It is understood that the Government will introduce summer time to operate between April 8 and September 23. ... ----- Oh. Before you jump on that last one look at the dates then realise that it was in a section of the paper headed "British Parliament." In conclusion there is little real unambiguous evidence out there that prooves "summer time" is more commonly used in Australia *to refer to* "Daylight Saving(s) Time" than the phrase "Daylight Saving(s) Time". In actual fact there is more evidence to prove the oposite. Formally the majority of Australian government websites refer to "Daylight Saving(s) Time" and this is the part of the TZ Database that we Australian users disagree with and wish to have changed. ----- search: legislation "standard time" "daylight saving" site:.gov.au About 25,600 results (0.21 seconds) search: legislation "standard time" "summer time" site:.gov.au About 15,600 results (0.14 seconds) N.B. ".gov.au" searches all state and federal official sites as they all use this domain. (e.g. Federal = just .gov.au, State i.e. Victoria = .vic.gov.au ). ----- An interesting video from the 1970's Four Corners program on the ABC (Australia's national broadcaster, ICYDK) on the introduction of "Daylight Saving" in Tasmania. Note the consistent use of that term "Daylight Saving", "Summer Time" is never mentioned (FYI It's a predominantly British term) and take a look at the flight attendant's bonnet! http://www.abc.net.au/archives/80days/stories/2012/01/19/3415208.htm Regards, Peter Stagg Web Developer - Radar Systems, AMDIS, +61 3 9669-4232, www.bom.gov.au ----- Date: Thu, 11 Apr 2013 09:50:04 +1000 From: Timothy Arceri <T.Arceri@bom.gov.au> Subject: [tz] [PATCH 0/2] Follow Australian common usage and update CST/CST to CST/CDT and EST/EST to EST/EDT etc [SEC=UNCLASSIFIED] To: "'tz@iana.org' (tz@iana.org)" <tz@iana.org> Message-ID: <7F491A8A71010C4E8B0266E3478C047A0220B1760322@BOM-VMBX-HO.bom.gov.au> Content-Type: text/plain; charset="us-ascii" <delitia> The reason for the current situation is documented in the Australasia data file:
From John Mackin (1991-03-06): "We in Australia have _never_ referred to DST as `daylight' time. It is called `summer' time. Now by a happy coincidence, `summer' and `standard' happen to start with the same letter; hence, the abbreviation does _not_ change..."
On 10 Apr, 2013, at 19:04 , Peter Stagg <P.Stagg@bom.gov.au> wrote:
Only tree of the four states in the "Eastern Standard Timezone" have daylight savings and they only have it for aprox. four of the twelve months in the year. And as someone pointed out before many web sites unwittingly use the TZ Database data to automatically timestamp pages. So the frequency of use of "EST" is destined to be much higher then "EDT" and therefore the search is meaningless.
I have no particular interest in what Australian time zone abbreviations should have been, or should be going forward, but I'm a bit interested in the topic mentioned above. If I needed to interpret a timestamp recorded by sites which "unwittingly use" the TZ database the TZ database itself makes it clear what I would need to know to disambiguate it: I need to know where in Australia the timestamp was taken (and I need to hope the timestamp wasn't taken in the 2 hours per year which can't be disambiguated, though the TZ database does also tell me which 2 hours are unavoidably ambiguous). I understand the effect of the change proposed is to reduce the information I need to know to disambiguate future timestamps recorded via unwitting use of the TZ database to "Australia", and this seems useful to me independent of what terms people in Australia actually use (or used) to describe the the current time on their clocks. I would note, however, that the proposed patch doesn't just limit itself to reducing the ambiguity of future timestamps not yet recorded, it also changes the database information about the abbreviations used for historical timestamps produced by the TZ database. While the issue of what time zone abbreviations people in Australia might have preferred to use is for others to debate there can be no dispute about the abbreviations the TZ database has used for the last 20 years, nor is there any way to change that, but by altering that data one is effectively removing the information about the history of the database itself that one would need to know to interpret timestamps already recorded with the "unwitting use" of the TZ database. Is there a reason to change the historical TZ database abbreviations rather than just making a change which is applied going forward? You can't really fix what has already happened, and attempting to pretend that it didn't happen that way just seems to increase the ambiguities that people with a need to interpret old timestamps produced with old versions of the TZ database need to deal with while having no offsetting advantages that I can see. As a policy matter I'd prefer that the bar to changing past TZ database data was set much higher (i.e. should require evidence of factual errors rather than just issues of opinion) than the bar to making changes which only effect the future. Dennis Ferguson
There is a use case to change them back to the introduction of daylight saving time if it is judged that that that has been the preferred abbreviation since that time. For the same reasons as going forward, a tool (such as a calendar) which reports past daylight saving time events remains ambigious for past dates if the abbreviations are not put into the database retroactively. I don't think its the responsibility of tz to report what tz did in the past - but to represent what was in common use in the past. On 2013-04-11 12:53, Dennis Ferguson wrote:
Is there a reason to change the historical TZ database abbreviations rather than just making a change which is applied going forward?
--
On Thu, Apr 11, 2013 at 7:33 PM, David Patte ₯ <dpatte@relativedata.com> wrote:
There is a use case to change them back to the introduction of daylight saving time if it is judged that that that has been the preferred abbreviation since that time. Not only then. The use is there for any environment that wants to be able to disambiguate. This is independent of what "has been the preferred abbreviation since that time" - by whom BTW?
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
On 2013-04-11 12:53, Dennis Ferguson wrote:
Is there a reason to change the historical TZ database abbreviations rather than just making a change which is applied going forward?
David makes the point very well here. As I stated in my email there was never any references of the current abbreviations use given when it was implemented and it has been a mistake from the beginning. As David says "I don't think its the responsibility of tz to report what tz did in the past - but to represent what was in common use in the past." This is also set out in the 'Procedures for Maintaining the Time Zone Database' document. "To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was."
You can't really fix what has already happened, and attempting to pretend that it didn't happen that way just seems to increase the ambiguities that people with a need to interpret old timestamps produced with old versions of the TZ database need to deal with while having no offsetting advantages that I can see.
There is no attempt to pretend that this didn't happen. Just fixing a past mistake. Your issue seems to be only with old timestamps however you fail to see that most high quality website (and the large amount of non website documents) over the last 20+ years have been fixing their pages to use the commonly used EDT etc anyway, these pages are usually much more important such as weather records, government reports etc than somebody’s first website they created in 1996. I think the benefit of fixing a past mistake finally removing any ambiguities out ways the few instances were the Eastern Summer Time abbreviation has been use wrongly in the past. Maybe it would be a good idea though to document exactly what has changed and from what date in the comments section of the datafile for future reference. Tim ________________________________________ From: tz-bounces@iana.org [tz-bounces@iana.org] On Behalf Of David Patte ₯ [dpatte@relativedata.com] Sent: Friday, 12 April 2013 3:33 AM To: tz@iana.org Subject: Re: [tz] [PATCH 0/2] Follow Australian common usage and update CST/CST to CST/CDT and EST/EST to EST/EDT etc [SEC=UNCLASSIFIED] There is a use case to change them back to the introduction of daylight saving time if it is judged that that that has been the preferred abbreviation since that time. For the same reasons as going forward, a tool (such as a calendar) which reports past daylight saving time events remains ambigious for past dates if the abbreviations are not put into the database retroactively. I don't think its the responsibility of tz to report what tz did in the past - but to represent what was in common use in the past. On 2013-04-11 12:53, Dennis Ferguson wrote:
Is there a reason to change the historical TZ database abbreviations rather than just making a change which is applied going forward?
--
On Thu, Apr 11, 2013 at 11:44 PM, Timothy Arceri <T.Arceri@bom.gov.au> wrote:
David makes the point very well here. As I stated in my email there was never any references of the current abbreviations use given when it was implemented and it has been a mistake from the beginning. As David says "I don't think its the responsibility of tz to report what tz did in the past - but to represent what was in common use in the past."
This is also set out in the 'Procedures for Maintaining the Time Zone Database' document. "To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was."
This is not applicable. "the average person on street would think the time actually is" - /time/ not /abbreviation/ And it is common practice that the maintainer invents new abbreviations. Did you look at inventend abbreviations as suggested at http://mm.icann.org/pipermail/tz/2013-April/019001.html ? So, here some lines from the Europe file: ---------- I invented the abbreviations marked `*' in the following table; # the rest are from earlier versions of this file, or from other sources. # -3:00 WGT WGST Western Greenland* # -1:00 EGT EGST Eastern Greenland* # 0:19:32.13 AMT NST Amsterdam, Netherlands Summer (1835-1937)* # 0:20 NET NEST Netherlands (1937-1940)* # 1:00:14 SET Swedish (1879-1899)* ---------- -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
Hi Tobias, I feel we are going around in circles here. As I have said before I understand what you are trying to do but I dont agree. All I'm trying to do is to get the database to use the abbreviations we use in Australia. I'm not trying to get all timezones to use a common international approach to abbreviations, I agree it would be excellent if there was some kind of international effort to create one but that is not something that the tz database should be creating and pushing. If there ever is such a standard created and countries actually start using it, only then should tz adopt it. As for any abbreviations created by this database I do not know the background of the creation. Nor do I know if this is what is actually used in those countries therefore I can not comment on them. If they are not in common use its up to someone to show this. maybe they don't use abbreviations in those countries so that's why they were created, I dont know therefore I can not comment. Its clear that you and I are trying to achieve two different things here. ________________________________________ From: tobias.conradi@gmail.com [tobias.conradi@gmail.com] On Behalf Of Tobias Conradi [mail.2012@tobiasconradi.com] Sent: Friday, 12 April 2013 8:28 AM To: Timothy Arceri Cc: tz@iana.org Subject: Re: [tz] [PATCH 0/2] Follow Australian common usage and update CST/CST to CST/CDT and EST/EST to EST/EDT etc [SEC=UNCLASSIFIED] On Thu, Apr 11, 2013 at 11:44 PM, Timothy Arceri <T.Arceri@bom.gov.au> wrote:
David makes the point very well here. As I stated in my email there was never any references of the current abbreviations use given when it was implemented and it has been a mistake from the beginning. As David says "I don't think its the responsibility of tz to report what tz did in the past - but to represent what was in common use in the past."
This is also set out in the 'Procedures for Maintaining the Time Zone Database' document. "To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was."
This is not applicable. "the average person on street would think the time actually is" - /time/ not /abbreviation/ And it is common practice that the maintainer invents new abbreviations. Did you look at inventend abbreviations as suggested at http://mm.icann.org/pipermail/tz/2013-April/019001.html ? So, here some lines from the Europe file: ---------- I invented the abbreviations marked `*' in the following table; # the rest are from earlier versions of this file, or from other sources. # -3:00 WGT WGST Western Greenland* # -1:00 EGT EGST Eastern Greenland* # 0:19:32.13 AMT NST Amsterdam, Netherlands Summer (1835-1937)* # 0:20 NET NEST Netherlands (1937-1940)* # 1:00:14 SET Swedish (1879-1899)* ---------- -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On Fri, Apr 12, 2013 at 2:38 AM, Timothy Arceri <T.Arceri@bom.gov.au> wrote:
Hi Tobias,
I feel we are going around in circles here. As I have said before I understand what you are trying to do but I dont agree. All I'm trying to do is to get the database to use the abbreviations we use in Australia. I'm not trying to get all timezones to use a common international approach to abbreviations, I agree it would be excellent if there was some kind of international effort to create one but that is not something that the tz database should be creating and pushing. If there ever is such a standard created and countries actually start using it, only then should tz adopt it.
You are mixing topics again. Where in the below email did I talk about "international approach to abbreviations"? Nowhere. Correct. Thank you,
As for any abbreviations created by this database I do not know the background of the creation. Nor do I know if this is what is actually used in those countries therefore I can not comment on them. If they are not in common use its up to someone to show this. maybe they don't use abbreviations in those countries so that's why they were created, I dont know therefore I can not comment. Its clear that you and I are trying to achieve two different things here.
I don't know what different things I tried to achieve in the email below. There I only pointed out a weakness in your argumentation. Tobias
________________________________________ From: tobias.conradi@gmail.com [tobias.conradi@gmail.com] On Behalf Of Tobias Conradi [mail.2012@tobiasconradi.com] Sent: Friday, 12 April 2013 8:28 AM To: Timothy Arceri Cc: tz@iana.org Subject: Re: [tz] [PATCH 0/2] Follow Australian common usage and update CST/CST to CST/CDT and EST/EST to EST/EDT etc [SEC=UNCLASSIFIED]
On Thu, Apr 11, 2013 at 11:44 PM, Timothy Arceri <T.Arceri@bom.gov.au> wrote:
David makes the point very well here. As I stated in my email there was never any references of the current abbreviations use given when it was implemented and it has been a mistake from the beginning. As David says "I don't think its the responsibility of tz to report what tz did in the past - but to represent what was in common use in the past."
This is also set out in the 'Procedures for Maintaining the Time Zone Database' document. "To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was."
This is not applicable. "the average person on street would think the time actually is" - /time/ not /abbreviation/
And it is common practice that the maintainer invents new abbreviations.
Did you look at inventend abbreviations as suggested at http://mm.icann.org/pipermail/tz/2013-April/019001.html ?
So, here some lines from the Europe file: ---------- I invented the abbreviations marked `*' in the following table; # the rest are from earlier versions of this file, or from other sources. # -3:00 WGT WGST Western Greenland* # -1:00 EGT EGST Eastern Greenland* # 0:19:32.13 AMT NST Amsterdam, Netherlands Summer (1835-1937)* # 0:20 NET NEST Netherlands (1937-1940)* # 1:00:14 SET Swedish (1879-1899)* ----------
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
tFrom: tobias.conradi@gmail.com [tobias.conradi@gmail.com] On Behalf Of Tobias Conradi [mail.2012@tobiasconradi.com]
This is also set out in the 'Procedures for Maintaining the Time Zone Database' document. "To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what >>the average person on street would think the time actually is, or in case of historical corrections, was."
This is not applicable. "the average person on street would think the time actually is" - /time/ not /abbreviation/
From 'Procedures for Maintaining the Time Zone Database':
"In order to correct historical inaccuracies, a new TZ name MAY be added when it is necessary to indicate what was the consensus view at a given time and location. Such TZ names are usually not added when the inaccuracy was prior to 1970" "Changes to existing entries SHALL reflect the consensus on the ground in the region covered by that entry."
On Thu, Apr 11, 2013 at 6:53 PM, Dennis Ferguson <dennis.c.ferguson@gmail.com> wrote: > > I would note, however, that the proposed patch doesn't just limit itself > to reducing the ambiguity of future timestamps not yet recorded, future and not yet recorded - do you use the terms in a tautological way? Or would you allow "timestamp" to refer to an existing time record of a future event? > it also > changes the database information about the abbreviations used for historical > timestamps produced by the TZ database. Same here, what is a historical timestamp? Does it include a time record made in 2000 for an event in 2010 and 2020? > While the issue of what time zone > abbreviations people in Australia might have preferred to use is for others > to debate there can be no dispute about the abbreviations the TZ database > has used for the last 20 years, nor is there any way to change that, Agreed. > but > by altering that data one is effectively removing the information about the > history of the database itself > that one would need to know to interpret > timestamps already recorded with the "unwitting use" of the TZ database. The archive is here: ftp://ftp.iana.org/tz/releases/ Depending on what you mean by time stamp, you would need to know when the stamping took place. > Is there a reason to change the historical TZ database abbreviations > rather than just making a change which is applied going forward? Yes, 1) make talking about events that happened in the past less ambiguous. 2) applying a change will always have some users stamping with the old abbreviations and new users with the new ones. So trying to limit a change to the second of the release does not yield the benefit you try to portrait. > You > can't really fix what has already happened, But the ambiguity introduced by what happened can be reduced, for time records of future and of past events. > and attempting to pretend > that it didn't happen No one is attempting that. > that way just seems to increase the ambiguities that > people with a need to interpret old timestamps produced with old versions > of the TZ database need to deal with So they have 10:00 EST for an NSW place during DST. How did they interpret it until now, as Summer Time or as Standard Time? What will be the problem if that is changed to say "EDT"? > while having no offsetting advantages > that I can see. Allow talking without ambiguity about past events. > As a policy matter I'd prefer that the bar to changing past TZ database > data was set much higher (i.e. should require evidence of factual errors > rather than just issues of opinion) than the bar to making changes which > only effect the future. Maybe for plain alterations of abbreviations, but for disambiguation, i.e. splitting A into A and B? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
Hi Dennis, If you "have no particular interest in what Australian time zone abbreviations" are or were I'm not sure why you would want to muddy the water other than apparently taking offence at the use of the phrase "unwitting use". Let me give you an example of what I mean by that phrase. This example is real and the reason I contacted the TZ list to begin with. As a developer (Engineer) I inherited a web application that I'm now responsible for maintaining here at the Australian Bureau of Meteorology - the radar viewer(s) <http://www.bom.gov.au/products/IDR023.loop.shtml>. It's a simple enough looking things but its made up of several interconnected scripts written in various languages and developed at different times over the past 15+ years. There is a box entitled Weather observations ad in it a human readable timestamp derived from the TZ database. Several weeks ago, when we were in daylight saving time, a visitor to our site pointed out that the timestamp had the abbreviation EST and said it should be EDT. Our helpdesk people saw this and agreed it should be EDT and escalated it to our media people who escalated it to our services policy people, who concurred, who escalated it to me. No one in that chain thought "Oh no that's right, its Eastern Summer Time", instead they all agreed that it should be "Eastern Daylight savings Time". The code that produced that timestamp was written some ten years ago and was more then likely written and tested during eastern daylight savings time and the developer at the time no-doubt thought that by using strftime they were doing the right thing and that it was a safe bet that during Daylight savings Time it would also do the right thing hence "unwitting use". Now regarding historical changes to the TZ database. In my view the point of the database is to record an accurate representation of time for the purposes of localisation and the point of the human readable/understandable portions of the data base is just that they be understood in any context (outside of the database). Our contention here is that there was an assumption made that was perpetuated for twenty+ years that Australians use the phrase "Eastern Summer Time" and the acronym EST to refer to "Eastern Daylight savings Time" when in fact we don't and didden't (for argument sake). To preserve this assumption in the database because that is what was in the database historically mean the database become self referential and reverencing. If we want to refer to a date/time in the past in the past in Melbourne, Australia for example 31/1/1917 3:30pm it should be appended with the abbreviation EDT because that date/time was during a "Daylight savings Time" period it should not be appended with the abbreviation EST because that is what the TZ database erroneously said it should be between 1991 and 2014. If you want evidence that we called it and call it "Daylight savings Time" in 1917 then search http://trove.nla.gov.au/newspaper for "Daylight saving". You will get more then 5,300 results returned for newspapers across Australia between 1910 and 1919 where that phrase is specifically used for that concept. And yes you will get more hits for "summer time" but the vast majority don't refer to the concept of "Daylight saving". Regards, Peter Stagg Web Developer - Radar Systems, AMDIS, +61 3 9669-4232, www.bom.gov.au -----Original Message----- From: Dennis Ferguson [mailto:dennis.c.ferguson@gmail.com] Sent: Friday, 12 April 2013 02:53 To: Peter Stagg Cc: 'tz@iana.org' Subject: Re: [tz] [PATCH 0/2] Follow Australian common usage and update CST/CST to CST/CDT and EST/EST to EST/EDT etc [SEC=UNCLASSIFIED] On 10 Apr, 2013, at 19:04 , Peter Stagg <P.Stagg@bom.gov.au> wrote:
Only tree of the four states in the "Eastern Standard Timezone" have daylight savings and they only have it for aprox. four of the twelve months in the year. And as someone pointed out before many web sites unwittingly use the TZ Database data to automatically timestamp pages. So the frequency of use of "EST" is destined to be much higher then "EDT" and therefore the search is meaningless.
I have no particular interest in what Australian time zone abbreviations should have been, or should be going forward, but I'm a bit interested in the topic mentioned above. If I needed to interpret a timestamp recorded by sites which "unwittingly use" the TZ database the TZ database itself makes it clear what I would need to know to disambiguate it: I need to know where in Australia the timestamp was taken (and I need to hope the timestamp wasn't taken in the 2 hours per year which can't be disambiguated, though the TZ database does also tell me which 2 hours are unavoidably ambiguous). I understand the effect of the change proposed is to reduce the information I need to know to disambiguate future timestamps recorded via unwitting use of the TZ database to "Australia", and this seems useful to me independent of what terms people in Australia actually use (or used) to describe the the current time on their clocks. I would note, however, that the proposed patch doesn't just limit itself to reducing the ambiguity of future timestamps not yet recorded, it also changes the database information about the abbreviations used for historical timestamps produced by the TZ database. While the issue of what time zone abbreviations people in Australia might have preferred to use is for others to debate there can be no dispute about the abbreviations the TZ database has used for the last 20 years, nor is there any way to change that, but by altering that data one is effectively removing the information about the history of the database itself that one would need to know to interpret timestamps already recorded with the "unwitting use" of the TZ database. Is there a reason to change the historical TZ database abbreviations rather than just making a change which is applied going forward? You can't really fix what has already happened, and attempting to pretend that it didn't happen that way just seems to increase the ambiguities that people with a need to interpret old timestamps produced with old versions of the TZ database need to deal with while having no offsetting advantages that I can see. As a policy matter I'd prefer that the bar to changing past TZ database data was set much higher (i.e. should require evidence of factual errors rather than just issues of opinion) than the bar to making changes which only effect the future. Dennis Ferguson
On 2013-04-11 17:53, Dennis Ferguson wrote:
I would note, however, that the proposed patch doesn't just limit itself to reducing the ambiguity of future timestamps not yet recorded, it also changes the database information about the abbreviations used for historical timestamps produced by the TZ database. While the issue of what time zone abbreviations people in Australia might have preferred to use is for others to debate there can be no dispute about the abbreviations the TZ database has used for the last 20 years, nor is there any way to change that, but by altering that data one is effectively removing the information about the history of the database itself that one would need to know to interpret timestamps already recorded with the "unwitting use" of the TZ database.
That's all the more reason to add the 'A' prefix to the new abbreviations, I think, just so it's easier to tell if an old date string is using the old abbreviation or the new one. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
I believe both Timothy and I prefer prefer AEST over EST, but it is a different issue than the Daylight saving time ambiguity issue, so we agreed that we we should probably make only the minimal changes that resolved the Daylight ambiguity issue with the least changes, since it was more likely to be a proposal that would be accepted into tz. We changed only the daylight time abbreviations to end the ambiguity. But if the tz maintainers believe that using AEST instead of EST would at the same time help resolve historical ambiguities caused by older versions of the tz database, I am sure we could re-roll the proposal to better suite the preferences of the maintainers. Until then, what our little sub-committee has proposed will likely stand as is. On 2013-04-12 7:16, Ian Abbott wrote:
On 2013-04-11 17:53, Dennis Ferguson wrote:
I would note, however, that the proposed patch doesn't just limit itself to reducing the ambiguity of future timestamps not yet recorded, it also changes the database information about the abbreviations used for historical timestamps produced by the TZ database. While the issue of what time zone abbreviations people in Australia might have preferred to use is for others to debate there can be no dispute about the abbreviations the TZ database has used for the last 20 years, nor is there any way to change that, but by altering that data one is effectively removing the information about the history of the database itself that one would need to know to interpret timestamps already recorded with the "unwitting use" of the TZ database.
That's all the more reason to add the 'A' prefix to the new abbreviations, I think, just so it's easier to tell if an old date string is using the old abbreviation or the new one.
--
On 2013-04-12 13:17, David Patte ₯ wrote:
I believe both Timothy and I prefer prefer AEST over EST, but it is a different issue than the Daylight saving time ambiguity issue, so we agreed that we we should probably make only the minimal changes that resolved the Daylight ambiguity issue with the least changes, since it was more likely to be a proposal that would be accepted into tz. We changed only the daylight time abbreviations to end the ambiguity.
But if the tz maintainers believe that using AEST instead of EST would at the same time help resolve historical ambiguities caused by older versions of the tz database, I am sure we could re-roll the proposal to better suite the preferences of the maintainers.
Until then, what our little sub-committee has proposed will likely stand as is.
Fine, but I think there will be friction against changing the abbreviations again when they've only just been changed! Personnally, I'd be in favour of using the 'A' prefix (although my opinion doesn't really count). Even if an Australian would normally use EST rather than AEST in everyday conversation, I'm sure they'd still recognize AEST in computer timestamp output and know what it meant! -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
On Fri, Apr 12, 2013 at 7:17 PM, David Patte ₯ <dpatte@relativedata.com> wrote:
I believe both Timothy and I prefer prefer AEST over EST, but it is a different issue than the Daylight saving time ambiguity issue, so we agreed that we we should probably make only the minimal changes that resolved the Daylight ambiguity issue with the least changes, since it was more likely to be a proposal that would be accepted into tz. We changed only the daylight time abbreviations to end the ambiguity.
I believe nearly all Australians either don't care or prefer AEST over EST, but understand your rationale. It solves the problems with systems entirely inside Australian borders. Cross border stuff will still need workarounds, such as international business or buggy software written overseas, but at least it is progress.
But if the tz maintainers believe that using AEST instead of EST would at the same time help resolve historical ambiguities caused by older versions of the tz database, I am sure we could re-roll the proposal to better suite the preferences of the maintainers.
I think a proposal for AEST would be preferable, with a fallback to EST, rather than attempting to divine the desires of the maintainers and end up with the less preferred option. Or was there an opinion I missed? -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/
On 12 April 2013 07:16, Ian Abbott <abbotti@mev.co.uk> wrote:
That's all the more reason to add the 'A' prefix to the new abbreviations, I think, just so it's easier to tell if an old date string is using the old abbreviation or the new one.
On 12 April 2013 08:17, David Patte ₯ <dpatte@relativedata.com> wrote:
I believe both Timothy and I prefer prefer AEST over EST, but it is a different issue than the Daylight saving time ambiguity issue
A different issue, certainly. But I think the argument here is that, although it can be discussed separately, adding the A should probably be implemented simultaneously with the broader xST/xDT change. If we don't, we could potentially have legacy timestamps out there stamped by versions of tz that use (1) xST/xST, (2) xST/xDT, and (3) AxST/AxDT. In the third case, nothing is ambiguous; but between the first two, the question of whether it's ambiguous is itself ambiguous! On 12 April 2013 08:17, David Patte ₯ <dpatte@relativedata.com> wrote:
We changed only the daylight time abbreviations to end the ambiguity.
Unfortunately, as shown above, this could actually make it worse. Since a goal of this broad proposal is indeed to reduce ambiguity, we should be extremely cautious against introducing ambiguity within ambiguity. Obviously, we can't change the past (and we shouldn't attempt to), so it is better to make a clean break and add a clear distinction between the two different notations so it is clear which is being used (and in the case of the older one, so users can decide whether further investigation is required to disambiguate). On 12 April 2013 09:34, Stuart Bishop <stuart@stuartbishop.net> wrote:
I believe nearly all Australians either don't care or prefer AEST over EST
In many ways, this helps, too. We have, at hand, a natural way of adding this distinction without resorting to inventing abbreviations (which we should not do). On 12 April 2013 08:17, David Patte ₯ <dpatte@relativedata.com> wrote:
But if the tz maintainers believe that using AEST instead of EST would at the same time help resolve historical ambiguities caused by older versions of the tz database, I am sure we could re-roll the proposal to better suite the preferences of the maintainers.
In short, I support both the xST/xDT and the A changes, and I feel that the adoption of either without the other would subvert the very goals that each tries to accomplish on its own. -- Tim Parenti On 12 April 2013 09:34, Stuart Bishop <stuart@stuartbishop.net> wrote:
On Fri, Apr 12, 2013 at 7:17 PM, David Patte ₯ <dpatte@relativedata.com> wrote:
I believe both Timothy and I prefer prefer AEST over EST, but it is a different issue than the Daylight saving time ambiguity issue, so we agreed that we we should probably make only the minimal changes that resolved the Daylight ambiguity issue with the least changes, since it was more likely to be a proposal that would be accepted into tz. We changed only the daylight time abbreviations to end the ambiguity.
I believe nearly all Australians either don't care or prefer AEST over EST, but understand your rationale. It solves the problems with systems entirely inside Australian borders. Cross border stuff will still need workarounds, such as international business or buggy software written overseas, but at least it is progress.
But if the tz maintainers believe that using AEST instead of EST would at the same time help resolve historical ambiguities caused by older versions of the tz database, I am sure we could re-roll the proposal to better suite the preferences of the maintainers.
I think a proposal for AEST would be preferable, with a fallback to EST, rather than attempting to divine the desires of the maintainers and end up with the less preferred option. Or was there an opinion I missed?
-- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/
From: tz-bounces@iana.org [tz-bounces@iana.org] On Behalf Of Stuart Bishop [stuart@stuartbishop.net] Sent: Friday, 12 April 2013 11:34 PM
On Fri, Apr 12, 2013 at 7:17 PM, David Patte ₯ <dpatte@relativedata.com> wrote:
I believe both Timothy and I prefer prefer AEST over EST, but it is a different issue than the Daylight saving time ambiguity issue, so we agreed that we we should probably make only the minimal changes that resolved the Daylight ambiguity issue with the least changes, since it was more likely to be a proposal that would be accepted into tz. We changed only the daylight time abbreviations to end the ambiguity.
I believe nearly all Australians either don't care or prefer AEST over EST, but understand your rationale. It solves the problems with systems entirely inside Australian borders. Cross border stuff will still need workarounds, such as international business or buggy software written overseas, but at least it is progress.
But if the tz maintainers believe that using AEST instead of EST would at the same time help resolve historical ambiguities caused by older versions of the tz database, I am sure we could re-roll the proposal to better suite the preferences of the maintainers.
I think a proposal for AEST would be preferable, with a fallback to EST, rather than attempting to divine the desires of the maintainers and end up with the less preferred option. Or was there an opinion I missed?
As David has said I and others at my organisation would much rather include the leading 'A'. But we also wanted to make sure that we at least got the daylight savings abbreviation fixed. Australians seem to have failed time and again over the past 20 years to get this issue resolve and I had come to the conclusion that a less preferred option was better than another failure. However some very good arguments have been raised since I've posted my patch for the inclusion of the leading 'A' if a change is to be made. I'm more than happy to create a second patch for consideration. Timothy Arceri
participants (9)
-
David Patte ₯ -
Dennis Ferguson -
Ian Abbott -
Peter Stagg -
Stuart Bishop -
Tim Parenti -
Timothy Arceri -
Tobias Conradi -
Tobias Conradi