Hi Masayoshi,

Currently I have not defined the new TimeZoneNames with +hh format, instead I 
have defined them as per the earlier convention like:

+            {"Asia/Barnaul", new String[] {"Barnaul Time", "BAT",
+                                           "Barnaul Summer Time", "BAST",
+                                           "Barnaul Time", "BAT"}},

+            {"Europe/Astrakhan", new String[] {"Astrakhan Time", "ASTT",
+                                               "Astrakhan Summer Time", 
"ASTST",
+                                               "Astrakhan Time", "ASTT"}},

+            {"Europe/Ulyanovsk", new String[] {"Ulyanovsk Time", "ULT",
+                                               "Ulyanovsk Summer Time", "ULST",
+                                               "Ulyanovsk Time", "ULT"}},



Please let me know if this is fine.


Regards,
Ramanand.

-----Original Message-----
From: Masayoshi Okutsu 
Sent: Wednesday, March 23, 2016 7:22 PM
To: Ramanand Patil; i18n-dev@openjdk.java.net
Cc: core-libs-...@openjdk.java.net
Subject: Re: RFR: 8151876: (tz) Support tzdata2016b

Sorry for this belated response.

I prefer to follow the tzdata abbreviations, like "+04". But that would require 
some major changes. An option would be not to define time zone names for the 
new zones with the +hh format.

Thanks,
Masayoshi

On 3/17/2016 4:38 AM, Ramanand Patil wrote:
> Hi all,
>
> Please review the latest TZDATA (tzdata2016b) integration to JDK9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151876
>
> Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/
>
> All the TimeZone related tests are passed after integration.
>
>   
>
> Please note that, as per the release notes: As a trial of a new system that 
> needs less information to be made up, the new zones use numeric time zone 
> abbreviations like "+04" instead of invented abbreviations like "ASTT".
>
> Since this is a trial system, I have ignored this in the current patch which 
> adds 3 new timezones. But I think it's worth discussing this new system along 
> with this bug and get the experts opinion on this.
>
> Do you think that JDK should also follow these IANA timezone naming system 
> for zone abbreviations in future ?  Will it be convenient to use such numeric 
> time zone abbreviations ? (Also, it looks like the abbreviations similar to 
> "+03/+04" will be used for the zones linked to the rule set with changing 
> letters like: EST/EDT for US, MSK/MSD for RU, etc..).
>
>   
>
> Regards,
>
> Ramanand.
>
>   

Reply via email to