> > The last phase could be extending the API to allow multiple simultaneous
> > time zones, detection of bad time zones, etc etc. This would involve API
> > changes or extensions, and breaks compatibility with system-supplied
> > infrastructure.
> One thing that wasn't clear to me, but could use investigation: if so
> many systems are using the same underlying timezone database info, maybe
> there is some commonality at a level below the ISO mktime/tzset/etc API.
> If we could make use of the system-provided TZ database at a lower level
> while still using our own APIs not tied to time_t, it'd answer the issue
> of compatibility with the surrounding system. (Which is a real issue,
> I agree --- we should be able to accept the system's standard TZ setting
> if possible.)
The fundamental problem (which of course can have a fundamental solution
;) is that a time zone database built with a 32-bit time_t will have
time zone info through 2038 only (it is a binary file with 32-bit time
fields -- almost certainly anyway). So if we have an extended time zone
infrastructure using something different for time_t we would need to
handle the case of reading non-extended time zones databases, which puts
us back to having limitations.
I'm guessing that a better approach might be to have our time zone stuff
inside our own API, which then could choose to call, for example,
mktime() or pg_mktime(), which could each have different signatures.
Then the heuristics for matching one to the other are isolated to our
thin API implementation, not to the underlying system- or pg-provided
libraries.
afaik there is no API provision for the "inverse time zone" problem of
matching "stringy time zones" to numeric offsets for input date/times.
The time zone databases themselves don't lend themselves to this, since
the tables have those stringy zones somewhere on the right hand side of
each row of information and the fields can change from year to year.
- Thomas
