From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | cbbrowne(at)cbbrowne(dot)com, Thomas Lockhart <lockhart(at)fourpalms(dot)org>, PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Redhat 7.3 time manipulation bug |
Date: | 2002-05-24 22:30:24 |
Message-ID: | 3CEEBF00.8050509@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2002-05-24 22:44:37 | Re: SRF rescan testing |
Previous Message | Tom Lane | 2002-05-24 22:09:06 | Re: Index tuple killing code committed |