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 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])