Unix时间戳是什么意思？
Unix 时间戳是一个数值，表示特定时刻距参考点的距离。参考点是 世界标准时间 1970 年 1 月 1 日 00:00:00它通常被称为 Unix 纪元或纪元。
如果使用秒，则参考点是 0, 1秒后 1，一天后 86400是的。由于时间以单个连续数字表示，而不是日历的年、月、日名称，因此即使在不同地区，也可以轻松比较同一时刻并按顺序排序。
| Unix秒 | UTC | 韩国标准时间 KST |
|---|---|---|
-1 | 1969-12-31 23:59:59 | 1970-01-01 08:59:59 |
0 | 1970-01-01 00:00:00 | 1970-01-01 09:00:00 |
1 | 1970-01-01 00:00:01 | 1970-01-01 09:00:01 |
86400 | 1970-01-02 00:00:00 | 1970-01-02 09:00:00 |
1704067200 | 2024-01-01 00:00:00 | 2024-01-01 09:00:00 |
为什么以1970年1月1日为标准？
这个日期并不是自然科学中时间开始的日期，而是基于 Unix 的时间表示中设置的参考点。一旦设置了参考点，该点之前的任何内容都可以表示为负数，该点之后的任何内容都可以表示为正数。
这里，1970年只是一个数值的起点，而不是可以表达的日期的绝对限制。如果您使用足够的数字和日期范围，则可以表示 1970 年之前甚至更远的未来的日期。 -31536000使用负数（例如秒）会使您向后移动大约一年。
纪元和时间戳之间的区别
纪元是起点，时间戳是从该起点测量的值。说“Unix 纪元是 1970-01-01 UTC”和“此事件的 Unix 时间戳是 1704067200”描述了不同的事情。
秒、毫秒、微秒、纳秒
Unix 时间并不总是使用秒。对于较短的间隔，请使用毫秒、微秒或纳秒。如果您不写下单位，则相同的数字可能会导致完全不同的日期。
| 单位 | 符号 | 1秒 | 2024-01-01 00:00:00 UTC 示例 |
|---|---|---|---|
| 秒 | s | 1 | 1704067200 |
| 毫秒 | ms | 1,000 | 1704067200000 |
| 微秒 | μs | 1,000,000 | 1704067200000000 |
| 纳秒 | ns | 1,000,000,000 | 1704067200000000000 |
数字长度只是一个线索
接近当前日期的正值中，秒通常为 10 位、毫秒为 13 位、微秒为 16 位、纳秒为 19 位。然而，较旧的日期、遥远的未来、带有前导零的值、负数和小数可能不符合这一规律。首选原始显示的单位，并检查转换后的日期是否在预期范围内。
首先怀疑 1,000 倍的错误。 如果结果接近 1970 年或比预期更远，请更改秒和毫秒并再次检查。
Unix 值没有时区
Unix 值代表 UTC 时刻，但区域名称（例如韩国或纽约）不存储在数字中。相同的值 1704067200如果以 UTC 表示，则为 2024 年 1 月 1 日的 0:00，或韩国当天的上午 9:00。
因此，“将时间戳更改为 KST”并不意味着将数字本身移动到不同的时刻，而是使用韩国时钟显示同一时刻。在 UTC 和 KST 之间切换时，原始 Unix 值不会改变。
固定时差和当地时区
目前，韩国标准时间全年为 UTC+09:00，因此可以应用 9 小时的时差。另一方面，在时差随季节变化的地区，仅通过增加几个小时来准确处理过去和未来是很困难的。您应该查看该日期适用的当地规则。
2024-01-01T09:00:00+09:00如果将日期和偏移量保留在一起，即使观看者来自不同地区，也可以将其解释为同一时刻。小数秒和精度
短于一秒的时刻可以用十进制数表示。 1704067200.5秒数比 2024 年 1 月 1 日 00:00:00 UTC 晚 500 毫秒。相同的值是 1704067200500也可以用毫秒来写。
更改单位并不会使单位比原始单位更准确。您可以将第二个整数乘以 1,000 以创建毫秒数，但新的三个零并不意味着实际测量精确到毫秒。区分原始测量精度和数字单位是一个好主意。
将纳秒视为日期时
纳秒值可能非常长，最终会以常规数字表示法被截断。如果需要进行精确比较，请将原始数字保留为整数，并确保保留人类可读日期中的小数位数。
负时间和闰秒
负数是 1970 年之前
-1秒为 1969-12-31 23:59:59 UTC，即纪元前一秒。由于韩国时间已经是 1970-01-01 08:59:59，因此不应仅通过查看 Unix 值的符号来确定本地日历年份。
闰秒不单独计算。
典型 POSIX 方式中的 Unix 时间不将闰秒计为单独的秒。所以它很少出现在UTC时钟中。 23:59:60并不简单地对应于一个正常的 Unix 值。当将两个 Unix 值相减的结果解释为非常长的天文经过时间时，了解这种差异非常重要。
不计算闰秒的Unix时间定义是 The Open Group 的 POSIX 时间解释您可以在这里查看。
2038年的问题是什么？
如果将 Unix 秒存储为 32 位有符号整数，则最大值为 2147483647是的。该值为2038-01-19 03:14:07 UTC，相同格式中不能包含添加1秒。这通常被称为 2038 问题。
这个问题并不意味着 Unix 时间概念本身将在 2038 年结束。这是由于所使用的碗数狭窄而造成的范围限制。使用更宽的有符号整数可以在 2038 年之后继续表示。
| Unix秒 | UTC | 意义 |
|---|---|---|
2147483646 | 2038-01-19 03:14:06 | 32 位范围内 |
2147483647 | 2038-01-19 03:14:07 | 最大 32 位 |
2147483648 | 2038-01-19 03:14:08 | 32 位有符号整数超出范围 |
如果您的日期超过 2038 年，例如长期存储事件、合同到期或出生日期，请检查您使用的文件或工具是否支持更广泛的范围。
Unix 时间与 ISO 8601 的比较
Unix 值很短，很容易按顺序进行比较，但人类阅读日期很困难，而且很容易省略单位。 ISO 8601 格式很长，但允许您包含日期、时间和 UTC 偏移量。
| 表达 | 例子 | 优点 | 注意事项 |
|---|---|---|---|
| Unix秒 | 1704067200 | 简短且易于排序 | 难以直观地读取单位和日期 |
| Unix 毫秒 | 1704067200000 | 表示1秒以下 | 如果您将其与秒混淆，日期将会发生显着变化。 |
| UTC ISO | 2024-01-01T00:00:00Z | 人类可读且时区清晰 | 必须严格遵循格式 |
| KST ISO | 2024-01-01T09:00:00+09:00 | 您可以立即知道韩国时间 | 偏移量和本地名称不是一回事 |
当传达重要时间时，保留 UTC ISO 格式与原始 Unix 值和单位是安全的。示例： 2024-01-01T00:00:00Z（1704067200 秒）.
验证顺序以防止错误的日期
- 确认数字单位。 检查 s、ms、μs、ns 符号或原始描述。
- 同时查看 UTC 和韩国时间。 检查日期是否因 9 小时而更改。
- 看看数字的位数是否符合您的预期。 目前，秒通常有 10 位数字，毫秒有 13 位数字。
- 保留小数点或负号。 当你删除一个符号时，它就变成了另一个时刻。
- 分享时请注明您的时区。 同时保留包含
Z或+09:00的日期。
结果是1970年左右
在许多情况下，您试图将毫秒值视为秒，或将秒视为毫秒。更改单位并重新检查。
韩国日期相差一天
世界标准时间 (UTC) 下午 3 点后，韩国已是第二天。不仅要比较时间，还要比较年、月、日。
末尾数字发生变化
将长纳秒视为常规数字可能会降低精度。与原始整数字符串进行比较。
官方标准和进一步阅读
时区规则可能会根据国家政策而变化。对于较早的历史时间或未来的当地时间，请查看该日期适用的 IANA 时区规则。
检查自己时间的工具
Unix 时间戳常见问题
Unix 时间戳基于什么时区？
参考时间为 UTC。 Unix值本身不包含本地时区，例如韩国或美国；时钟和日期取决于选择显示的时区。
Unix 时间什么时候为 0？
Unix 时间 0 是 1970 年 1 月 1 日 00:00:00 UTC。韩国标准时间当天上午 9 点。
如果时间戳有 10 位，那么它总是秒吗？
对于接近现在的正值，10 位数字通常（但并非总是）秒。对于1970年附近、遥远的未来以及带有前导零的值，无法仅通过长度确定单位，因此请一起检查原始单位和转换日期。
Unix 时间计算闰秒吗？
典型 POSIX 方式中的 Unix 时间不将闰秒计为单独的秒。因此，UTC时钟中显示的闰秒和Unix秒之间的对应关系不同于累积秒的简单概念。
所有时间戳都会出现2038问题吗？
不会。2038 问题是将 Unix 秒存储为 32 位有符号整数时出现的范围限制。使用更宽的整数格式，您还可以表示 2038 年之后的年份。
我应该共享时间戳还是 ISO 8601？
带时区的 ISO 8601 格式方便人们阅读和查看时间表，而 Unix 值则方便对数字进行比较和排序。重要时刻，将 UTC ISO 格式与原始 Unix 值和单位放在一起可以帮助减少误解。