[tz] Java & Rearguard

Paul Eggert eggert at cs.ucla.edu
Wed Jun 5 20:41:15 UTC 2019


On 6/5/19 3:51 AM, Stephen Colebourne wrote:
> But it has been this way for 20+ years and isn't
> going to change any time soon. It also produces an answer that as
> correct as the underlying data (CLDR)

I'm not sure it's fair to pass this buck to CLDR. CLDR is trying to 
maintain timezone strings that are suitable for Java (as almost nobody 
else uses them) and so if Java is messed up, CLDR will likely be equally 
messed up, to stay compatible with Java.

Even now (that is, with rearguard format to pacify Java) there are still 
problems with time in Ireland due to Java's confusion on this issue (as 
mimicked by CLDR). See the example at the end of this email, where 
OpenJDK 12 says that local time should be called "GMT" / "Greenwich Mean 
Time" in Ireland on January 1, 1970, which is obviously wrong as Irish 
clocks were one hour ahead of UTC then (and Java gets the UTC offset 
right) and nobody on the ground then would have called that time "GMT".

That being said, I'm not that pessimistic about whether these problems 
will be fixed. They are obviously fixable; all we need is for Oracle to 
do the fix in OpenJDK, and I'm sure that they can do it if they want to. 
In the meantime the problems do not seem to be that big a deal in practice.

$ jshell
|  Welcome to JShell -- Version 12.0.1
|  For an introduction type: /help intro

jshell> var epoch = java.time.Instant.EPOCH
epoch ==> 1970-01-01T00:00:00Z

jshell> var zone = java.time.ZoneId.of("Europe/Dublin")
zone ==> Europe/Dublin

jshell> var dtf = 
java.time.format.DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss Z z 
(zzzz)")
dtf ==> Value(YearOfEra,4,19,EXCEEDS_PAD)'-'Value(MonthOf ... RT)' 
''('ZoneText(FULL)')'

jshell> epoch.atZone(zone).format(dtf)
$4 ==> "1970-01-01 01:00:00 +0100 GMT (Greenwich Mean Time)"




More information about the tz mailing list