Tom Lane wrote:
> Well, that's the zeroth-order approximation. We should take the
> opportunity to get out from under the mktime()/tzset() API. The real
> idea here is to make use of the timezone database info in the ways that
> Postgres needs. Some things that are not good about mktime()/tzset():
>
> * Arbitrary restrictions on range of dates. We certainly don't want to
> be limited by a 32-bit time_t, whether you think it's signed or not.
> The APIs should be recast in terms of PG's preferred internal
> representations. (Lockhart would be the man to point you in the right
> direction here, not me.)
>
> * No way to tell whether a user-provided timezone name is actually good.
>
> * No support for concurrent access to multiple zones, short of flushing
> all memory of one zone to load the next. Although we do not really need
> this now, I can foresee wanting it. I'd be inclined to store all the
> info about a particular zone in some struct that can be referenced by
> a pointer; that would give us the flexibility to have multiple such
> structs floating around a backend in the future (perhaps living in a
> hashtable indexed by timezone name?)
>
> My guess is that we want to borrow the parts of the tzcode library that
> are associated with reading a tz database file and loading it into some
> suitable internal representation; there's probably not a lot else that
> we'll want to use as-is.
Well, this does sound a bit more involved than I was envisioning. There
are a few items wrt SRFs that I should finish first, but I'll come back
to this afterward if no one else does first.
Joe
