Skip to main content

New Scientist, Feedback, Year 2038 Problem

A letter I wrote to New Scientist in response to Feedback, p. 56, 31 Jan 2015, No. 3006, regarding their mention of the Year 2038 Problem:


Dear New Scientist,

Re: Feedback, p. 56, 31 Jan 2015, No. 3006

The ‘date in December 1901’ referenced is likely 1901-12-13 20:45:52 UTC [1]. However, this only applies to software programs storing dates as seconds calculated externally to the database, or programs using certain kinds of timestamp types [2]. But there is no need to do this, as major databases provide proper date handling which is more sophisticated than simply using 64 bits, and not vulnerable to the Year 2038 Problem. Using these main date types, PostgreSQL has a latest date in Year 294276 [3], and MySQL, Microsoft SQL Server, and Oracle Database in Year 9999 [4] [5] [6], assuming storage of the time component is required. However, there are also ways to mitigate against these limitations, too. Thus, [it] is likely that resolving the issue for embedded systems will indeed be more difficult.

Peace,
tiredpixel

[1]: Unix Epoch - 2^31 (c.f. the latest date, Unix Epoch + 2^31 - 1, because of 0)
[2]: MySQL ‘timestamp’ type, https://dev.mysql.com/doc/refman/5.7/en/datetime.html
[3]: PostgreSQL ‘timestamp’ type, http://www.postgresql.org/docs/9.4/static/datatype-datetime.html
[4]: MySQL ‘DATETIME’ type, https://dev.mysql.com/doc/refman/5.7/en/datetime.html
[5]: Microsoft SQL Server ‘datetime2’ type, https://msdn.microsoft.com/en-us/library/bb677335.aspx
[6]: Oracle Database ‘NUMBER’ type, http://docs.oracle.com/cd/B28359_01/server.111/b28318/datatype.htm