Re: Redhat 7.3 time manipulation bug

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