HiveBrain v1.2.0
Get Started
← Back to all entries
patternsqlMinor

MySQL year 2038 vulnerable

Submitted by: @import:stackexchange-dba··
0
Viewed 0 times
mysql2038yearvulnerable

Problem

I was studying Drupal and asked this question:

https://drupal.stackexchange.com/questions/45443/why-timestamp-format-was-chosen-for-users-created-field/45446#45446

I decided to check, how the CMS will behave after the end of Unix epoch. Set my local date to 01.01.2040 and rebooted.

To my surprise, the site didn't work at all. And the reason was, that MySQL was down. I tried to connect manually and got an error:

>mysql -uroot -ppass
ERROR 2003 (HY000): Can't connect to MySQL server on 'localhost' (10061)


I am using MySQL 5.5 on Win XP. Why such strange behaviour?

Solution

The rationale is probably based on which datetime representation is easier to handle for both MySQL and the OS (in this case, Windows XP)

  • DATETIME takes up 8 bytes



  • TIMESTAMP takes up 4 bytes



Their Data and Time Ranges would differ greatly. Note further differences in the MySQL Documentation


The DATETIME type is used for values that contain both date and time
parts. MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD
HH:MM:SS' format. The supported range is '1000-01-01 00:00:00' to
'9999-12-31 23:59:59'.


The TIMESTAMP data type is used for values that contain both date and
time parts. TIMESTAMP has a range of '1970-01-01 00:00:01' UTC to
'2038-01-19 03:14:07' UTC.


MySQL converts TIMESTAMP values from the current time zone to UTC for
storage, and back from UTC to the current time zone for retrieval.
(This does not occur for other types such as DATETIME.) By default,
the current time zone for each connection is the server's time. The
time zone can be set on a per-connection basis. As long as the time
zone setting remains constant, you get back the same value you store.
If you store a TIMESTAMP value, and then change the time zone and
retrieve the value, the retrieved value is different from the value
you stored. This occurs because the same time zone was not used for
conversion in both directions. The current time zone is available as
the value of the time_zone system variable. For more information, see
Section 10.6, “MySQL Server Time Zone Support”.

Since both MySQL and Windows have TimeZone Support, it was probably in MySQL's best interest to have mysqld more Windows-aware. This would probably be a secret incentive to get your MySQL database out of Windows and into Linux. (My Conspiracy Theory)

Context

StackExchange Database Administrators Q#25302, answer score: 3

Revisions (0)

No revisions yet.