我想我今天写的一些软件将在30年内使用.但我也意识到,很多都是基于UNIX传统,即将时间暴露为自1970年以来的秒数.
#include
#include
#include
void print(time_t rt) {
struct tm * t = gmtime(&rt);
puts(asctime(t));
}
int main() {
print(0);
print(time(0));
print(LONG_MAX);
print(LONG_MAX+1);
}
执行结果:
1970年1月1日00:00:00
2008年8月30日星期六18:37:08
星期二1月19日3时14分07秒2038
12月13 日星期五20:45:52 1901
函数ctime(),gmtime()和localtime()都将一个时间值作为参数,该时间值表示自Epoch(1970年1月1日00:00:00 UTC;参见时间(3))以来的时间(以秒为单位).
我想知道作为程序员在这个领域是否有任何主动做的事情,或者我们是否相信所有软件系统(又称操作系统)将来会如何神奇地升级？
更新看起来确实64位系统是安全的:
import java.util.*;
class TimeTest {
public static void main(String[] args) {
print(0);
print(System.currentTimeMillis());
print(Long.MAX_VALUE);
print(Long.MAX_VALUE + 1);
}
static void print(long l) {
System.out.println(new Date(l));
}
}
12月31日星期三16:00:00太平洋标准时间1969年
2008年8月30日星期六12:02:40 PDT 2008
8月16日星期六23:12:55太平洋标准时间292278994
太阳12月02日08:47:04太平洋标准时间292269055
但那一年292278994呢？
我已经编写了time.h的可移植替代品(目前只有localtime(),gmtime(),mktime()和timegm()),即使在32位机器上也使用64位时间.它旨在被放入C项目中作为time.h的替代.它正在Perl中使用,我打算用它修复Ruby和Python的2038个问题.这为您提供了+/- 2.92亿年的安全范围.
您可以在y2038项目中找到代码.请随时向问题跟踪器发布任何问题.
至于"这不会成为另外29年的问题",请仔细阅读这份标准答案清单.简而言之,事情发生在未来,有时你需要知道什么时候.我还介绍了这个问题,什么不是解决方案,什么是解决方案.
哦,不要忘记很多时间系统都没有处理1970年之前的日期.东西发生在1970年之前,有时你需要知道什么时候.
您可以随时实施RFC 2550并永远安全;-)
已知的宇宙具有有限的过去和未来.宇宙的当前年龄在[Zebu]估计为10**10和2*10**10年之间.在[Nigel]估计宇宙的死亡发生在10**11年,在[德雷克]估计发生在10**12年的封闭宇宙(大崩溃)或10**14年一个开放的宇宙(宇宙的热死).
符合Y10K标准的程序可以选择将它们支持的日期范围限制为与宇宙的预期寿命一致的日期.符合Y10K标准的系统必须接受从过去的10**12年到未来10**20年的Y10K日期.符合Y10K标准的系统应该在过去和未来接受至少10**29年的日期.
京公网安备 11010802040832号 | 京ICP备19059560号-6 