On Tue, Jul 10, 2001 at 04:15:03PM -0400, Michael Meltzer wrote:
> it not a bug, it is a feature, complain to Tomas Riche, 68 years (2038-1970)
> is all the seconds that fit in 2^31 or a signed long number, which is how
> the timestamp was defined a long time ago, it was always figured that some
> would change the base year sooner or later. Or the programmer view ;-) that
> "I will be retired by then so it will be the next person problem", or better
> yet "The software will last that long ha ha ha :-). I subspect someone with
> refine it to a 64 bit number one of these days. But this is not a bug.
So it's not a bug that there are ~19 days in 2038 that MySQL (via
unix_timestamp) can't handle? I understand that 2^31 seconds after 1970
runs out in 2038 -- that's actually how I found this bug. A countdown
program I wrote determines how long until a given event. In real life,
2^31 (0x7fffffff) seconds is:
January 19 2038 at 03:14:07 GMT
Which means that (in GMT) there is 19 days, 3 hours, 14 minutes, and 8
seconds that MySQL can't deal with. By definition, that's a bug in MySQL,
not the definition of time_t being a signed 32-bit value.
--
Randomly Generated Tagline:
"To the engineer, the world is a toy box full of sub-optimized and
feature-poor toys." - Scott Adams
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
