On Wed, 24 Sep 1997, John Cowan wrote:
I would be interested in hearing from people who want to help improve the currently rather feeble Java 1.1 implementation of time zones.
Jeffrey Sean Connell wrote:
This couldn't possibly have come at a better time.
I agree, this would be the proverbial Good Thing. I need a a similar interface for a C++ locale facet. If the level of traffic gets too great for this mailing list, we can take it off-line. I see several problems in current implementations that I would not want to propagate into an object interface. First, a 32-bit epoch would be a big mistake; we can use a "double", relative to Jan 1, 2001, which would give microsecond accuracy for now, with precision decreasing as we pass and recede from that date; or we could use a 64-bit integer count of microseconds from practically any choice of epochs. Each representation has its advantages. The second familiar problem is the crossover periods for time changes. Converting from microseconds-past-epoch to local time is well-defined; but conversion back demands accommodation to local time that doesn't exist (during "spring forward" gaps); and [2] local time that is ambiguous (before or after "fall back"). Since there isn't any really satisfactory solution to these, they just need to be visible (and unavoidable) in the interface. The third problem is that the TZ database on line is available only in a form that would be very clumsy to handle in an on-line transaction. That is, if it changes at all (which happens frequently), there is no way to check for rule changes in a particular locality without downloading the whole thing and unpacking it, which would introduce an unacceptable delay in an interactive application. To check only locally depends on "system administrators" to install updates, but most Java platforms will have (for practical purposes) no system administrator. One solution would be a network of TZ servers that can hand out up-to-date fragments of the database on demand, similar to DNS service. A good time zone class would adapt to different sources of zone information in much the way IP name lookup happens, but with fallback to a local cache when the network is inaccessible. Probably the IETF should be involved in this last bit ... do any IETF members monitor this list? Nathan Myers ncm@cantrip.org http://www.cantrip.org/