[tz] [PATCH 0/2] Follow Australian common usage and update CST/CST to CST/CDT and EST/EST to EST/EDT etc [SEC=UNCLASSIFIED]

[Peter Stagg]

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 at gmail.com] 
Sent: Friday, 12 April 2013 02:53
To: Peter Stagg
Cc: 'tz at 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 at 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