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@cantrip.org