Joe Conway <[EMAIL PROTECTED]> writes:
> I don't understand precisely what need to be done, but I'll give it a
> shot if you get me pointed in the right direction.
> <downloads and looks at code>
> I see that tzcode2002c.tar.gz includes a mktime() function. Is the idea
> to pull this out (with just whatever support it needs), incorporate it
> into PostgreSQL source (perhaps in a new src/backend/utils/tz directory)
> and use this in place of the system provided mktime()?
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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
