Re: Recent glibc time_t redefinition?
On 03-Feb-03, 07:37 (CST), Richard Braakman <firstname.lastname@example.org> wrote:
> On Mon, Feb 03, 2003 at 12:13:28PM +1000, Andrew Pollock wrote:
> > I'm assuming it was deliberate also, to address the 2038 bug. I've seen
> > much talk of it back in 2000 in Google, but nothing more recent.
> Hmm, do I understand correctly that we've introduced a 1970 bug in
> order to move the 2038 bug to 2106?
I don't think you call it "introducing a bug"; code that expected the
standard Unix time functions to work with dates before 01/01/1970 has
always been broken.
> A far better strategy would be to start implementing RFC 2550
> ("Y10K and Beyond") as soon as possible. Then we'd be permanently
> rid of these problems.
Dream on. Yes, that's what we should be doing, but that doing so will
cause people to do things correctly is being hopelessly optimistic.
After all, pre-1970 dates have *never* been correct, have *always* been
documented as incorrect, but enforcing this somehow caused problems with
the supposedly portable postgresql? (I'm stressing *portable* here;
I know that there are systems with a different epoch, and different
representations of time_t.)
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net