如果我想使用过去/未来数百万年的日期和时间来工作,我将如何在 C/C++/C# 中做到这一点?
例如,假设我正在研究一种算法来查看彗星是否会撞击地球?是否有商业或开源库可以做到这一点?
大多数 DateTime 值只能使用几年。Unix 将在 2038 年用完!
托尼
如果我想使用过去/未来数百万年的日期和时间来工作,我将如何在 C/C++/C# 中做到这一点?
例如,假设我正在研究一种算法来查看彗星是否会撞击地球?是否有商业或开源库可以做到这一点?
大多数 DateTime 值只能使用几年。Unix 将在 2038 年用完!
托尼
由于存在闰秒(其中一个定于 12 月 31 日,距现在几周),您无法将未来的 UTC 日期精确到秒。没有人知道闰秒何时会添加到日历中,因为没有人知道未来地球自转的速度会继续减慢。
好吧,不要直言不讳,但如果它会在 1700 年后撞击地球,我认为我们不需要知道实际日期。
除非是星期二。
永远无法掌握星期二的窍门。
如果典型日期时间变量提供的时间跨度太小,您有两种选择:
你应该选择哪一个取决于你到底想做什么。但总的来说,我的建议是选项 2。当我们谈论世纪或千年时,毫秒通常并不那么重要......
谈到天文事件时,地球的哪一部分面向太阳并不重要,即有日光。因此,日历和日期也无关紧要。你应该简单地使用时间。例如 64 位 time_t 就足够了。
即使你确实使用时间,请记住,三体系统(如地球-太阳-木星)是混乱的。在遥远的未来预测地球的位置有相当大的误差。
64 位 time_t 将一直工作到 292,277,026,596 年。
您只需要更多位来存储值和/或使用更大的时间增量来表示时间戳。如果这还不够(并且取决于您的精度要求)或使用浮点数,则可以使用为非常大的数字设计的数学库/API,而不是 ms。
C# 中的 DateTime 对象从 1.1.0001 变为 12.31.9999。在最早日期为 1735 年之类的 SQL Server 中,它甚至更受限制。
您几乎将不得不自己写一些东西或尝试从其他人那里收集一些东西。前进可能更容易(除了闰秒之外)。这里有一些关于日历的非常好的信息。
我认为问题在于不知道彗星会在周五还是周日撞击,而是彗星是否会撞击。我想这意味着您可以将千分之一秒的时间建模为 64 位 long long 类型。你可以解决2130亿年。然后,您可以有一个例程,将其映射回有意义的完整日期......