List:General Discussion« Previous MessageNext Message »
From:Michael Widenius Date:September 2 1999 1:02am
Subject:Re: MYSQL year 2069 complaint
View as plain text  
>>>>> "Steve" == Steve Ruby <stever@stripped> writes:

Steve> I am not understanding something in your reponse here. 
Steve> so the function unix_timestamp() should not work after
Steve> 2038? But MySQL TIMESTAMP is okay till 2099?

It will be when the Unix OS will start supporting unsigned
32 bit times or 64 bit times.

Steve> I was only referring to the result of unix_timestamp()
Steve> for exampleon NT and HP-UX (3.22.24 and 3.22.23b respectively)

Steve> I get

Steve> Your MySQL connection id is 49 to server version: 3.22.23b

Steve> Type 'help' for help.

mysql> select unix_timestamp('2050-01-01');
Steve> +------------------------------+
Steve> | unix_timestamp('2050-01-01') |
Steve> +------------------------------+
Steve> |                            0 |
Steve> +------------------------------+
Steve> 1 row in set (0.00 sec)

Steve> before some time in 2038 I get results, after that just zero
Steve> I didn't look at the size of the number it is possible it is
Steve> overflowing whatever type of integer it is.

The problem is that MySQL uses the localtime() call to decode the
stored value.  This will not work until the OS timestamp is fixed.

As MySQL stores the timestamp as an unsigned long int it will be able to
handle 2099 when localtime() is fixed.

MYSQL year 2069 complaintKesavan J1 Sep
  • Re: MYSQL year 2069 complaintPaul DuBois1 Sep
    • Re: MYSQL year 2069 complaintSteve Ruby1 Sep
      • Re: MYSQL year 2069 complaintMichael Widenius2 Sep
        • Re: MYSQL year 2069 complaintSteve Ruby2 Sep
          • Re: MYSQL year 2069 complaintEd Carp2 Sep
          • Re: MYSQL year 2069 complaintMichael Widenius2 Sep