1

我正在尝试http://www.epochconverter.com/我可以做 100 年，但是当我进入 99 年时，它似乎崩溃并报告 1999 而不是 0099。这是一个错误吗？纪元时间应该能够表示多远。

我还尝试将 MIN_LONG+1 插入到 joda-time 报告 -292275055-05-16T16:47:04.192Z 所以基本上是年 -292275055 这听起来比 1999 年更正确，并且 epochconverter.com 甚至无法解析 min long .

允许的纪元时间最小值是多少？我可以使用分钟长吗？

谢谢，院长

4

5 回答 5

4

理论上，没有限制。“纪元时间”只是定义时间点（1970 年 1 月 1 日，格林威治标准时间午夜）之前/之后的秒数；使用足够宽的数字类型，您可以用这些术语来描述任何时间。

在实践中，这样的时间值在某些限制之外变得毫无意义：

  • 带符号的 32 位整数的最小值约为 -20 亿，对应于 1901 年末的日期。

  • 如果您对日期使用浮点类型，它将在某个点之后失去分辨率。不要对时间值使用单精度（32 位）浮点数；他们对当前日期的分辨率约为两分钟（128 秒）！不过，在可预见的未来，64 位浮点数还是可以的，因为它们可以准确地表示所有 32 位整数。

  • 时区在 1900 年左右之前没有标准化，因此试图表示在那之前的时间是不准确的事情。

  • 公历在 1582 年之前没有定义（直到 1920 年代才被普遍使用！），因此尝试在很久以前的日期上使用标准日期转换例程会得到不正确的结果。

  • 同样，Anno Domini（“AD”）历法直到公元 525 年才被定义。此外，请注意没有第 0 年。

  • 一些库可能有其他任意限制或限制。例如，您在这里遇到的是 Javascript 日期库假定小于 100 的年份是 1900 到 1999 之间年份的简写。

于 2013-07-02T18:01:29.920 回答
3

通过“纪元时间”，我猜你的意思是维基百科所说的“ Unix 时间”，即自 1970-01-01 00:00:00 UTC 以来的秒数。使用 32 位有符号整数，它可以表示从 1901-12-13 到 2038-01-19 (GMT) 的日期（您可以通过在 epochconverter 中输入 -2^31 和 2^31-1 的值来找到您链接的网站）。Unix 时间本身没有最小或最大日期或精度，唯一的限制是你使用什么样的数字来定义它。

Joda-Time显然具有自纪元以来定义为毫秒的时间瞬间，使用long（64 位有符号整数）来存储它。这具有从 -292275055（或 292,275,055 BC，如果您愿意）到 +292278994（292,278,994 AD）的年份范围。

于 2013-07-02T17:52:06.470 回答
-1

1970 年 1 月 1 日在类 Unix 系统上。

于 2013-07-02T17:45:12.863 回答
-1

1970 年 1 月 1 日。如果您在 64 位系统中进入纪元时间之前，那么您将得到一个下溢，这将产生比宇宙预期时间大 5 倍的时间。这就是导致 iPhone 5S+ 出现错误 53 的原因

于 2016-04-25T01:17:05.410 回答
-1

它将您的输入年份 99 解释为 1999 年的原因是因为它更有可能使用 Javascript 函数 Date.parse() 来解析您的日期，该日期具有这种特殊的异常。

您可以在另一个在线时间戳解析器（例如http://www.convertunixdate.com/ ）上获得正确解析的时间戳- 您可能需要将年份输入为 4 位数字，以确保它没有被更改。

于 2017-06-03T22:54:51.753 回答