我正在尝试http://www.epochconverter.com/我可以做100年，但是当我去99年时，它似乎打破并报告1999而不是0099.这是一个错误吗？能够代表的纪元时代到底有多远。
我也尝试插入MIN_LONG + 1到joda-time报告-292275055-05-16T16：47：04.192Z所以基本上年-292275055听起来比1999更正确而epochconverter.com甚至无法解析分钟。
允许的纪元时间的最小值是多少？我能用min min吗？
感谢， 迪安
答案 0 :(得分：3)
按“纪元时间”，我猜你的意思是维基百科称之为“Unix time”，即自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）到+292278994（公元292,278,994）。
答案 1 :(得分：3)
理论上，没有限制。 “纪元时间”只是定义时间点之前/之后的秒数（1970年1月1日，格林威治标准时间午夜）;如果数字类型足够宽，您可以用这些术语描述任何时间。
在实践中，这样的时间价值在某些限制之外变得毫无意义：
带符号的32位整数的最小值约为20亿，与1901年末的日期相对应。
如果您使用浮点类型的日期，它将失去超过某一点的分辨率。不要将单精度（32位）浮点数用于时间值;它们的当前日期分辨率约为2分钟（128秒）！但是，在可预见的未来，64位浮点数很好，因为它们可以完全代表所有32位整数。
时区在1900年之前没有标准化，因此在此之前尝试代表时间是不准确的事情。
公历不是在1582年之前定义的（并且直到20世纪20年代才被普遍使用！），所以尝试在远期的日期使用标准的日期转换例程会产生错误的结果。
同样，Anno Domini（“AD”）日历直到公元525年才定义。另外，请注意，没有第0年。
某些库可能有其他任意限制或限制。例如，你在这里遇到的是Javascript日期库假设年龄小于100的年份是1900年到1999年之间的简写。
答案 2 :(得分：0)
1970年1月1日，类Unix系统。
答案 3 :(得分：0)
1970年1月1日。如果你在64位系统的大纪元时间之前去，那么你将获得一个下溢，这将产生比宇宙的预期时间大5倍的时间。这就是导致iPhone 5S +
的错误53的原因答案 4 :(得分：0)
它将你的输入年99解释为1999年的原因是因为它更有可能使用Javascript函数Date.parse（）来解析你的日期，这具有这种特殊的异常。
您可以在另一个在线时间戳解析器（例如http://www.convertunixdate.com/）上获取正确解析的时间戳 - 您可能需要输入您的年份作为4位数字，以确保它不会被更改。