Patch use LHDT/LHST/LHHDT since HD HS DD DS are common practice
Patch australasia.20130411.withLHHDT is linked from http://anna.info/wiki/ANNA_time_zone_database - I don't link to the actual location, because that may change. And I don't email, because I don't know what the email client does with the file. The patch includes AEST/AEDT ACST/ACDT AWST/AWDT CWST/CWDT LHDT/LHST/LHHDT -------- 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. No single use of single "D" for non-1:00 saving has been found by me. There is one single "D" in a LHDT but there it referred to a 1:00 saving. Be consistent, apply common practice established by the maintainers and use: HD 0:30 LHHDT Australia/Lord_Howe For non 1:00 DST offsets the database contains: 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 -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
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.
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 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. Rather abbreviations are meant to reflect what is used by the Country they are defined for.
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."
________________________________________ From: tz-bounces@iana.org [tz-bounces@iana.org] On Behalf Of Tobias Conradi [tobias.conradi@gmail.com] Sent: Friday, 12 April 2013 9:03 AM To: tz@iana.org mailing list Subject: [tz] Patch use LHDT/LHST/LHHDT since HD HS DD DS are common practice Patch australasia.20130411.withLHHDT is linked from http://anna.info/wiki/ANNA_time_zone_database - I don't link to the actual location, because that may change. And I don't email, because I don't know what the email client does with the file. The patch includes AEST/AEDT ACST/ACDT AWST/AWDT CWST/CWDT LHDT/LHST/LHHDT -------- 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. No single use of single "D" for non-1:00 saving has been found by me. There is one single "D" in a LHDT but there it referred to a 1:00 saving. Be consistent, apply common practice established by the maintainers and use: HD 0:30 LHHDT Australia/Lord_Howe For non 1:00 DST offsets the database contains: 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 -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
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/
On 2013-04-12 01:54, Timothy Arceri 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.
You could attach the patch as well as they tend to get less mangled that way. That's what ado does. Either that, or learn to use "git send-email" which seems to do a good job of not mangling patches! -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
From: Ian Abbott [abbotti@mev.co.uk] Sent: Friday, 12 April 2013 8:50 PM
On 2013-04-12 01:54, Timothy Arceri 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.
You could attach the patch as well as they tend to get less mangled that way. That's what ado does.
I thought about doing this but decided against it because anyone that receives this list as a digest will have the attachments scrubbed.
Either that, or learn to use "git send-email" which seems to do a good job of not mangling patches!
I did not realise git send-email could send out patch files I always assumed they were generated from the repository. Thanks for pointing this out.
On 13/04/13 00:22, Timothy Arceri wrote:
From: Ian Abbott [abbotti@mev.co.uk]
Either that, or learn to use "git send-email" which seems to do a good job of not mangling patches!
I did not realise git send-email could send out patch files I always assumed they were generated from the repository. Thanks for pointing this out.
Both, really. The patches it sends out are generated from your local repository. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
participants (3)
-
Ian Abbott -
Timothy Arceri -
Tobias Conradi