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.
[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