[tz] Java & Rearguard
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.
| 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
dtf ==> Value(YearOfEra,4,19,EXCEEDS_PAD)'-'Value(MonthOf ... RT)'
$4 ==> "1970-01-01 01:00:00 +0100 GMT (Greenwich Mean Time)"
More information about the tz