On Fri, Apr 12, 2013 at 2:54 AM, Timothy Arceri <T.Arceri@bom.gov.au> wrote:
And I don't email, because I don't know what the email client does with the file.
I emailed the patch purely for easy review from those on the list. This is common practice in open-source programming projects. The source itself is not meant to be actually pulled out of the emails.
I may do the same in the future. Thanks.
The bom.gov.au-patch introduces new syntax, which for itself might be fine, but this new syntax is less informative than the established one and might be seen as deterioration to the whole database.
We are not inventing anything new It has been proven you do in the scope of the DB.
just using what is commonly used in Australia, as far as I've seen there is no defined syntax used for abbreviations other than that which are trying to create. Did you see the list?
DD 2:00 NDDT America/St_Johns IDDT Asia/Jerusalem DS 2:00 MDST - Moscow Double Summer Time, BDST - British Double Summer Time HD 0:30 CHDT America/Belize CHDT EHDT America/Santo_Domingo HS 0:30 UYHST America/Montevideo IHST Asia/Colombo CKHST Pacific/Rarotonga HS 0:20 GHST Africa/Accra
Rather abbreviations are meant to reflect what is used by the Country they are defined for. This is not common practice for abbreviations. Repeating: IANA has WIT Western Indonesia Time, but in the country which is Indonesia WIT is Waktu Indonesia Timur = Eastern Indonesia Time.
From 'Procedures for Maintaining the Time Zone Database': "Changes to existing entries SHALL reflect the consensus on the ground in the region covered by that entry."
This is point three of three, headed by: "The criteria for updates to the database include the following:" 1) There may be other criteria. And common practice in the database is to not use "D" for non 1:00 saving. It never was used that way. 2) "consensus on the ground" - with respect to abbreviations is almost a joke, since abbreviations are only based on the English language. 3) The points 1 and 2 in the RFC talk about zone name and zone creation, the fundamental elements for time data storage in the IANA time zone database, not about abbreviations or comments. The whole http://tools.ietf.org/html/rfc6557 does not mention "abbreviation". So there is a hardly applicable RFC-(Feb 2012)-only-phrase standing against established syntax. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/