1

格林威治标准时间 2038 年 1 月 19 日 03:14:07 现在距离我们不到 20 年。这是 UNIX 的 32 位时间戳翻转的时间。我正在设计一些当时可能仍在使用的 MySQL 表。

这就是所谓的2038 年问题。

看来，从我在 MariaDB 10.3 上尝试过的东西来看，使用TIMESTAMP数据类型会在日期翻转后为日期戳产生错误 1292（不正确的日期时间值）。

将这些表设计为面向未来的良好做法是什么？我可以使用DATETIME数据，但TIMESTAMP在时区方面有一些非常有用的功能。

未来的 MySQL 版本（更不用说 Linux 和其他 UNIX 衍生产品）是否有可能升级？

4

3 回答 3

3

使用 BigInts 存储 unix 时间戳。这在功能上等同于 TIMESTAMP 类型，尽管缺少一些附加的糖。但是，如果在应用程序级别您很乐意只使用 UNIX 时间戳，那根本没有区别，至少到目前为止，在数据库层处理偶尔的 UNIX_TIMESTAMP(...) / FROM_UNIXTIME( …） 称呼。这将使你远远超过 2038 年。

虽然我预计 MySQL / Maria mob 会在 Xy 版本中创建一些 hack，作为升级路径的一部分自动更新 TimeStamp 字段。请注意，它可能会在 2038 年 1 月 18 日发布。;)

无论如何，如果您想将来证明，将 BIGINT 视为 UNIX 时间戳就是您的答案。

于 2018-09-15T14:39:24.210 回答
0

拿出你在 1998 年写的代码。找一台机器来运行它。您可能需要找到一个软盘驱动器来加载它。

现在，问问自己“20 年后代码和硬件会发生什么”？

我建议，除了政府合同之外，2018 年编写的所有代码都将在 2038 年之前被丢弃。

1998 年，MySQL 运行版本 3.xx；我不想用 10 年（或 20 年）的极点来触及它。从那时起，内部格式发生DATETIME了变化，CHARACTER SETs添加了许多优化，添加了子查询，修复了错误等等。

我在最后一段中的观点是，随着 MySQL 在未来 20 年的成熟，你今天写的任何东西都会发生应用程序的变化。解决 2038 年问题只是众多变化之一。

于 2018-10-01T17:16:47.890 回答
0

使用这两个函数并将时间戳存储为十进制

CREATE FUNCTION from_unixtime_fixed (v DECIMAL(16,6))
    RETURNS DATETIME(6) DETERMINISTIC
    RETURN DATE_ADD(FROM_UNIXTIME(0), INTERVAL v second);
CREATE FUNCTION unix_timestamp_fixed (v DATETIME(6))
    RETURNS DECIMAL(16,6) DETERMINISTIC
    RETURN TIMESTAMPDIFF(SECOND, FROM_UNIXTIME(0), v);

示例用法：select unix_timestamp_fixed('2039-01-01');

返回 2177449200.000000

select from_unixtime_fixed(2177449200.100000);

返回 2039-01-01 00:00:00.100000

如果您对毫秒不感兴趣，请将 DECIMAL(16,6) 减少到 DECIMAL(16,0)

于 2021-06-07T14:53:23.940 回答