Tom Lane wrote:
> Thomas Lockhart <lockhart@fourpalms.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...
I am not really excited about distributing a timezone database as part
of PostgreSQL, and it wouldn't match the OS's timezone. (We do need a
64-time time_t, but I think we can wait to get closer to 2038.) Can we
detect if glibc is being used for the compile (easy), and substitute a
non-broken mktime in the link path ahead of glibc's mktime? Seems that
would be the easiest solution.
Of course, pre-1970 dates then wouldn't match the OS on glibc systems,
but that seems like a win. :-)
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
