time zone object

[Nathan Myers]

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 at cantrip.org  http://www.cantrip.org/