FW: Java zoneinfo reader
Stuart is not on the time zone mailing list; be sure to direct replies appropriately. --ado
-----Original Message----- From: Stuart D. Gathman [SMTP:stuart@bmsi.com] Sent: Thursday, June 01, 2000 5:11 PM To: tz@elsie.nci.nih.gov Subject: Java zoneinfo reader
I have a Java implementation of java.util.TimeZone that reads the /etc/zoneinfo database. It is not yet 2038 compliant - I propose a solution in the docs. I will browse your site to see if the zoneinfo database handles 2038 yet.
From: Stuart D. Gathman [SMTP:stuart@bmsi.com] Sent: Thursday, June 01, 2000 5:11 PM
I will browse your site to see if the zoneinfo database handles 2038 yet.
zic's input can, but its output can't.
Is that code freely available? Currently it says "Copyright (C) 1999 Business Management Systems, Inc." with no further explanation, which means it's proprietary and I shouldn't read it, for the usual unfortunate legal reasons.
Paul Eggert wrote:
From: Stuart D. Gathman [SMTP:stuart@bmsi.com] Sent: Thursday, June 01, 2000 5:11 PM
I will browse your site to see if the zoneinfo database handles 2038 yet.
zic's input can, but its output can't.
Does my proposal sound reasonable? (High order bits are implied by the monotonically increasing values in the transition table). Should I start working on mods to ZoneInfo and zic? The advantage of the transition table is that it handles any concievable rule variation at runtime. With current histories, the format requires about 1K / century.
Is that code freely available? Currently it says "Copyright (C) 1999 Business Management Systems, Inc." with no further explanation, which means it's proprietary and I shouldn't read it, for the usual unfortunate legal reasons.
I have added the LGPL. The code was largely copied from the zoneinfo library - so that license should apply. I hope that LGPL is compatible. The package should, of course, be changed for an "official" version.
Date: Mon, 05 Jun 2000 13:06:09 -0400 From: "Stuart D. Gathman" <stuart@bmsi.com> Does my proposal sound reasonable? (High order bits are implied by the monotonically increasing values in the transition table). That won't allow any transitions that are more than 2**32 seconds apart. I think this assumption is unsafe. For example, if Congo standardizes on Central African Time in 2034, Africa/Kinshasa will have two adjacent transitions more than 2**32 seconds apart, as its most recent transition was in early November 1897. It'd be nicer if we could solve the problem in the more general case. We need to do this for 64-bit time_t anyway (e.g. 64-bit Solaris 8), so the problem isn't specific to Java. We need to extend the compiled tz file format, ideally in a backward-compatible way.
participants (3)
-
Olson, Arthur David (NCI) -
Paul Eggert -
Stuart D. Gathman