| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
| Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, hannu(at)tm(dot)ee, teg(at)redhat(dot)com, lamar(dot)owen(at)wgcr(dot)org, masm(at)fciencias(dot)unam(dot)mx, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Redhat 7.3 time manipulation bug |
| Date: | 2002-05-23 02:19:04 |
| Message-ID: | 1782.1022120344@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:
>> Why should we rely on broken glibc and the standard? Why don't we make
>> our own mktime() and use it on all platforms.
> The downside to doing that is that we then take over maintenance of the
> code and, more importantly, the timezone database.
> But it might be the best thing to do.
I've been sorta thinking the same thing. We could get out from under
the Y2038 issue, and also eliminate a whole lot of platform
dependencies. Not to mention sillinesses like being unable to recognize
a bad timezone name when it's fed to us.
Exactly how much work (and code bulk) would we be taking on? I've
never looked at how big the timezone databases are...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Naeslund(f) | 2002-05-23 02:42:13 | Re: Redhat 7.3 time manipulation bug |
| Previous Message | Thomas Lockhart | 2002-05-23 01:51:07 | Re: Redhat 7.3 time manipulation bug |