| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
| Cc: | Joe Conway <mail(at)joeconway(dot)com>, cbbrowne(at)cbbrowne(dot)com, PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Redhat 7.3 time manipulation bug |
| Date: | 2002-05-25 00:09:49 |
| Message-ID: | 22423.1022285389@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> 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).
I'm not sure that the time zone database tables store time_t's at all.
They certainly could be coded not to use 'em; but I do not know exactly
how various vendors have chosen to represent the data.
A random extract from the tzdata2002c files looks like:
Zone America/Chicago -5:50:36 - LMT 1883 Nov 18 12:00
-6:00 US C%sT 1920
-6:00 Chicago C%sT 1936 Mar 1 2:00
-5:00 - EST 1936 Nov 15 2:00
-6:00 Chicago C%sT 1942
-6:00 US C%sT 1946
-6:00 Chicago C%sT 1967
-6:00 US C%sT
which might well be represented with separate y/m/d/h/m fields...
certainly we'd choose some such thing if we have to implement it
ourselves.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | cbbrowne | 2002-05-25 00:37:24 | Re: Redhat 7.3 time manipulation bug |
| Previous Message | Thomas Lockhart | 2002-05-25 00:04:11 | Re: Redhat 7.3 time manipulation bug |