JSON Web Token和2038年问题

Question

JSON Web Token是一个相对较新的标准（于2015年5月发布），但他们决定采用UNIX时间戳来表示日期。

这难道不会让该标准在实现过程中潜在地面临2038年问题吗？相反，选择像ISO8601这样的标准似乎更加有未来性。

为什么要选择其中一个而不是另一个呢？

- Spack

---

我认为由于UNIX时间戳并不总是以32位值存储，RFC依赖于大多数机器在2038年到达时将运行64位值的事实。通过使用64位值，问题被推迟到非常遥远的未来。 - Arthur Attout

@ArthurAttout 这就是问题所在。为什么要冒险使用另一种数据类型呢？ - Spack

Answer 1

JSON对数字的精度没有限制，因此JWT本身格式没有溢出问题。一切都取决于实现方式。

一些实现方式，比如JavaScript，将所有JSON数字视为双精度浮点数。虽然它们不会在宇宙热寂之前溢出，但它们将在不到3亿年内开始变得不准确，并且随着时间的推移问题会越来越严重（例如你创建一个有效期为1小时的令牌，但该值无法表示为双精度浮点数，最近的值是2小时，因此它直到2小时后才过期）。

其他实现方式可能使用64位有符号整数。这些将在3000亿年后溢出，远在太阳变成红巨星并吞噬地球之后。

唯一容易受到Y2038问题影响的实现方式是在解析日期时决定使用32位有符号整数。这样的实现方式是愚蠢的。无论选择哪种格式，都不能防止愚蠢的行为-ISO8601在这方面无济于事，因为虽然它可能是传输协议中的格式，但每个实现都将把它解析成从某个时期以来的某些时间单位，因为这是所有计算机处理日期的方式，也是实际进行计算（例如令牌是否过期）的唯一方式。因此，每个实现，即使使用ISO8601，都容易选择代表日期的数字表示形式精度过低，无法处理特定时间之后的日期，包括选择有符号32位整数来表示从1970年开始以秒为单位的日期，如Y2038问题。每个实现都需要选择适当大小的数字类型来表示其解析的日期，你可能会发现它们都这样做（如果没有，应该报告错误）。

因此，对于JWT使用UNIX纪元后的秒数作为日期没有任何问题。

- James Roper

---

我非常喜欢阅读这篇文章。在使用64位有符号整数时，“这些将在3000亿年后溢出，远在太阳变成红巨星并吞噬地球之后。”是我希望在这个行业中更经常说的话。 - hylander0

Answer 2

Unix时间戳并不那么糟糕——与解析日期相比，它们绝对可以帮助您简化一堆计算。

在大多数情况下，JWT中的日期声明应该与NOW()（考虑到exp声明）进行比较，因此在那里使用时间戳是有意义的。

我不会担心Y2038问题，因为32位系统将面临比发行JWT更大的问题。

- odino