[tz] Patch use LHDT/LHST/LHHDT since HD HS DD DS are common practice [SEC=UNCLASSIFIED]

[Tobias Conradi]

On Fri, Apr 12, 2013 at 2:54 AM, Timothy Arceri <T.Arceri at 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/