时间戳(UnixTimestamp)与 《2038年问题》

时间戳是从格林威治时间1970年01月01日00时00分00秒(北京时间1970年01月01日08时00分00秒)起至现在的总秒数。

现在时间戳的长度是十位(1435113975--2015/6/24 10:46:15)。

要到 2286/11/21 01:46:40 才会变成11位(10000000000),距离现在还有 271年。

不同时区获取的时间不一样,生成的时间戳会不一样,比如中国是东八区(+8),美国东部是西五区(-5),两地的时差是13小时,北京比纽约要早13个小时;

一般从中国的12月15日乘飞机去美国, 到达时间就是美国的12月15日,在中国是12月16日。

这样就导致跨时区验证时间戳会不准的情况。

所以要把日期协调成世界时间。

C#中 DateTime.ToUniversalTime 方法会把本地时间协调成世界时间。

测试代码:

string date = DateTime.Now.ToString();//本地时间
string dateAmerica = DateTime.Now.AddHours(-13).ToString();//模拟美国东部时间
object back = (DateTime.Parse(date).ToUniversalTime().Ticks - 621355968000000000) / 10000000;//协调全球时间的时间戳
object back2 = (DateTime.Parse(date).Ticks - 621355968000000000) / 10000000;//不协调全球时间的时间戳
object backA = (DateTime.Parse(dateAmerica).Ticks - 621355968000000000) / 10000000;//模拟美国东部时间的时间戳
Console.WriteLine("时间:" + date);
Console.WriteLine("协调全球时间的时间戳:" + back);
Console.WriteLine("时间戳的类型:" + back.GetType());
Console.WriteLine("时间戳的长度:" + back.ToString().Length);
Console.WriteLine("不协调全球时间的时间戳:" + back2);
Console.WriteLine("此时美国时间的时间戳:" + backA);

输出:

《2038年问题》

在计算机应用上,2038年问题可能会导致某些软件在2038年无法正常工作。所有使用UNIX时 间表示时间的程序都将受其影响,因为它们以自1970年1月1日经过的秒数(忽略闰秒)来表示时间。这种时间表示法在类Unix(Unix-like)操 作系统上是一个标准,并会影响以其C编程语言开发给其他大部份操作系统使用的软件。在大部份的32位操作系统上,此“time_t”数据模式使用一个有正 负号的32位元整数(signedint32)存储计算的秒数。依照此“time_t”标准,在此格式能被表示的最后时间是2038年1月19日 03:14:07,星期二(UTC)。超过此一瞬间,时间将会被掩盖(wrap around)且在内部被表示为一个负数,并造成程序无法工作,因为它们无法将此时间识别为2038年,而可能会依个别实作而跳回1970年或1901 年。错误的计算及动作可能因此产生。

其实就是在32位系统上,长度溢出导致的异常。

时间: 2024-10-08 20:50:38

时间戳(UnixTimestamp)与 《2038年问题》的相关文章

2038年问题

 2038年问题 在计算机应用上,2038年问题可能会导致某些软件在2038年无法正常工作.所有使用UNIX时间表示时间的程序都将受其影响,因为它们以自1970年1月1日经过的秒数(忽略闰秒)来表示时间.这种时间表示法在类Unix(Unix-like)操作系统上是一个标准,并会影响以其C编程语言开发给其他大部份操作系统使用的软件. 在大部份的32位操作系统上,此"time_t"数据模式使用一个有正负号的32位元整数(signedint32)存储计算的秒数.也就是说最大可以计数的秒数

洛谷 P2655 2038年问题

P2655 2038年问题 题目描述 网络时代,机会与危机共存.“千年虫”解决之后,会不会有新的“虫”出现?回答是肯定的,“2038年”就是一个新的关卡. 也许大家都已经知道计算机的2000年问题是什么概念,但是什么时候又冒出来一个2038年问题的呢? 用C语言编制的程序不会碰到2000年问题,但是会有2038年问题.这是因为,大多数C语言程序都使用到一个叫做“标准时间库”的程序库,这个时间库用一个标准的4字节也就是32位的形式来储存时间信息. 当初设计的时候,这个4字节的时间格式把1970年1

“千年虫问题”、“2038年问题”、什么是闰年

(1)先温习一下什么是闰年(Leap Year) 闰年是公历中的名词.闰年分为普通闰年和世纪闰年. 普通闰年:能被4整除但不能被100整除的年份为普通闰年.(如2004年就是闰年,1999年不是闰年); 世纪闰年:能被400整除的为世纪闰年.(如2000年是世纪闰年,1900年不是世纪闰年); 闰年(Leap Year)是为了弥补因人为历法规定造成的年度天数与地球实际公转周期的时间差而设立的.补上时间差的年份为闰年.闰年共有366天(1-12月分别为31天,29天,31天,30天,31天,30天

时间戳过了2038年以后不能用了怎么办?

如何解决程序员面临的时间戳2038的问题?当2038年过后,时间戳无法继续使用怎么办?strtotime date都相继失效,代码还能跑吗? 别急 还有这个 运行结果 还能再坚持一段时间,哈哈哈

php 2038年问题

在mysql中存放日期时可以存放整数 (int),  而int可以存放的数据最大为4294967295(无符号), 而php最大为2147483647, 要显示一个大于2038年日期,该如何处理 ? 1.更换平台,换成64位系统. 2.使用datetime类 <?php $date = new DateTime('@2444486400'); //设置中国时间 $date->setTimezone(new DateTimezone('PRC')); echo $date->format(

简述unix时间戳

unix时间戳是从1970年1月1日(UTC/GMT的午夜)开始所经过的秒数,不考虑闰秒. Unix时间戳(英文为Unix epoch, Unix time, POSIX time 或 Unix timestamp) 是从1970年1月1日(UTC/GMT的午夜)开始所经过的秒数,不考虑闰秒. UNIX时间戳的0按照ISO 8601规范为 :1970-01-01T00:00:00Z. 一个小时表示为UNIX时间戳格式为:3600秒:一天表示为UNIX时间戳为86400秒,闰秒不计算. 在大多数的

Java 获取 Unix时间戳

unix时间戳是从1970年1月1日(UTC/GMT的午夜)开始所经过的秒数,不考虑闰秒. 在大多数的UNIX系统中UNIX时间戳存储为32位,这样会引发2038年问题. 但是,因为需求是需要int类型的UNIX时间戳. 开始的时候我是这样设计的. /** * 获取当前事件Unxi 时间戳 * @return */ public static int getUnixTimeStamp(){ long rest=System.currentTimeMillis()/1000L; return (i

unix时间戳time_t与UTC时区的关系

一般我用C写unix时间戳是这样子的 #include<stdio.h> #include<time.h> void printfDateTimeStr(struct tm *stm){ char weekday[][4]={"天","一","二","三","四","五","六"}; printf("timestr=%04d-%02d

为什么要使用Unix时间戳

概念: UNIX时间戳:Unix时间戳(英文为Unix epoch, Unix time, POSIX time 或 Unix timestamp) 是从1970年1月1日(UTC/GMT的午夜)开始所经过的秒数,不考虑闰秒. UNIX时间戳的0按照ISO 8601规范为 :1970-01-01T00:00:00Z. 一个小时表示为UNIX时间戳格式为:3600秒:一天表示为UNIX时间戳为86400秒,闰秒不计算. 在大多数的UNIX系统中UNIX时间戳存储为32位,这样会引发2038年问题或