我们可以改为：

FROM_UNIXTIME(0) + INTERVAL -957632400 SECOND

该FROM_UNIXTIME功能受TIMESTAMP数据类型的允许范围限制，该范围是标准的32位无符号整数范围1970-01-01至2038-01-something。其他软件已更新为支持64位带符号整数，但是MySQL尚未提供该功能（至少在5.1.x中不提供）。

当我们需要更大的范围（例如，1970年1月1日之前的日期）时，MySQL中的解决方法是避免使用TIMESTAMP数据类型，而改用DATETIME数据类型。

我们可以使用该DATE_ADD函数从1970年1月1日减去秒，如下所示：

SELECT DATE_ADD('1970-01-01 00:00:00',INTERVAL -957632400 SECOND)

注意：
在进行这些类型的计算时，您可能需要考虑UTC的时区“偏移”。MySQL会将DATETIME值解释为time_zone当前MySQL会话的设置中指定的值，而不是UTC（time_zone = '+00:00'）

跟进：

问： 好的，这意味着如果我们选择低于‘1970-01-01 00:00:00’的日期，那么负值将保存在数据库中，否则它将是正数。对？–软基因

答： 唔，没有。如果选择1970年1月1日之前的date /
datetime值，则MySQL将返回1970年1月1日之前的DATE或DATETIME值。如果存储1970年1月1日之前的DATE或DATETIME值，则MySQL将在1月1日之前存储DATE或DATETIME值。
，1970年，在这些数据类型支持的允许范围内。（类似于0001-01-01至9999吗？）

如果您需要在数据库中存储非常大的正整数和负整数，则可能会将它们存储在定义为的列中BIGINT。

DATE列的内部表示形式需要3字节的存储空间，而DATETIME则需要8个字节的存储空间（MySQL版本5.6.4以下。DATE和DATETIME值的内部表示形式和存储在5.6.4中已更改）

所以不，MySQL不会将1970年之前的日期值存储为“负整数”。

如果您考虑一下，MySQL可以自由地实现他们想要的任何存储机制。（并且每个存储引擎都可以随意将其表示序列化到磁盘上，但可以使用它。）

为什么一个日期要3个字节？

MySQL具有的一种选择（我不代表这是完成的方式）可能是将日期分解为年份的年月日组成部分。

范围内的整数值的表示形式-需要-

• 0 - 9999 - 14位

• 0 - 12 - 4位

• 0 - 31 - 5位

总共23位，恰好适合3个字节。这仅表明MySQL不必将1970年1月1日之前的日期值表示为负整数，因此我们不应该假设它确实如此。（但是，如果我们正在为MySQL设计存储引擎，那么我们实际上只关心这一详细级别。）