time zone object
ncm at cantrip.org
Thu Sep 25 18:50:57 UTC 1997
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
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  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?
ncm at cantrip.org http://www.cantrip.org/
More information about the tz