Tom Lane wrote: > Thomas Lockhart <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
