When distros update their timezone data, the data used by OpenJDK also
needs to be updated. At present, this is difficult as OpenJDK uses a
hardcoded path (${java.home}/jre/lib/zi} for timezone data with no
option to override it.
A bug was filed for this issue back in 2007 and there was some
discussion on the mailing lists:
http://mail.openjdk.java.net/pipermail/i18n-dev/2007-August/000001.html
but no patch was committed.
I've updated the patch and provide a revised version in this webrev:
http://cr.openjdk.java.net/~andrew/6593486/webrev.01/jdk.patch
When the class is initialised, it attemps to read the property
sun.zoneinfo.dir from ${java.home}/jre/lib/tz.properties. If it finds
a value, it checks that the file ${sun.zoneinfo.dir}/ZoneInfoMappings
exists as confirmation that this is indeed a directory of timezone
data. If this or anything prior fails (no property, no tz.properties,
etc.) it will fall back to the current solution. Thus, the new code
only has an effect if a tz.properties is added with the specified
property.
I confirmed this with strace. With no tz.properties:
331 open("/mnt/builder/swing/j2sdk-image/jre/lib/tz.properties",
O_RDONLY) = -1 ENOENT (No such file or directory)
...
331 access("/mnt/builder/swing/j2sdk-image/jre/lib/zi/ZoneInfoMappings",
R_OK) = 0
With tz.properties containing 'sun.zoneinfo.dir=/usr/share/tzdata':
359 open("/mnt/builder/swing/j2sdk-image/jre/lib/tz.properties", O_RDONLY) = 4
359 fstat(4, {st_mode=S_IFREG|0644, st_size=35, ...}) = 0
359 fcntl(4, F_GETFD) = 0
359 fcntl(4, F_SETFD, FD_CLOEXEC) = 0
359 lseek(3, 54661116, SEEK_SET) = 54661116
359 read(3,
"PK\3\4\n\0\0\0\0\0\26u\31;\"\372\336\250\264\7\0\0\264\7\0\0%\0\0\0"...,
30) = 30
359 lseek(3, 54661183, SEEK_SET) = 54661183
359 read(3,
"\312\376\272\276\0\0\0003\0K\t\0\16\0,\n\0\17\0-\t\0\16\0.\t\0\16\0/\t\0\16"...,
1972) = 1972
359 read(4, "sun.zoneinfo.dir=/usr/share/tzdat"..., 8192) = 35
359 fstat(4, {st_mode=S_IFREG|0644, st_size=35, ...}) = 0
359 lseek(4, 0, SEEK_CUR) = 35
359 lseek(4, 0, SEEK_END) = 35
359 lseek(4, 35, SEEK_SET) = 35
359 read(4, ""..., 8192) = 0
359 read(4, ""..., 8192) = 0
359 close(4) = 0
359 stat("/usr/share/tzdata/ZoneInfoMappings", 0x7ff1cdcbe650)
The webrev is prepared against the swing forest as I was informed
earlier that the i18n forest is not in use.
Is it ok to commit this to swing-gate?
Thanks,
--
Andrew :-)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
