Re: Redhat 7.3 time manipulation bug

Tom Lane wrote:
> 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...

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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026