time zone object

Nathan Myers ncm at cantrip.org
Mon Sep 29 23:59:50 UTC 1997


John Cowan
> Markus Kuhn wrote:
> > Therefore, I consider anything less than 64-bit timestamps and
> > nanosecond resolution in a new portable clock interface to be somewhat
> > old-fashioned and ignorant about current hardware capabilities.
> 
> And I consider a representation that is limited to the years
> 1901 through 2038 rather short-sighted. 

It's clear that time_t, timespec, and the Java whatsit are not the 
final word on time/date representations.  In C++, a TimeZone class
could be a template that accepts any such representation, specialized 
for the ones actually used, and suffering limitations each imposes 
only when that one is used.

What we need to work out is the interface for a class that 
computes adjustments to whatever representation is in use.  
This means 

(1) an infrastructure (protocols, conventions) to provide up-to-date
    zone information to programs that need it; and

(2) a call interface that allows a reasonable person to write code 
    that operates on wall-clock time with some hope of getting it 
    right.

As John Cowan pointed out, HTTP would suffice as a low-level protocol 
for access to zone tables across the net, but we also need to identify
authoritative sources of up-to-date information; and specify caching 
of retrieved information with preference for the cached data up to an 
expiry date.  This requires representing the expiry date in the cached
file.  Does the "zic" format permit a datestamp?

Nathan Myers
ncm at cantrip.org




More information about the tz mailing list