讨论一下时间戳的范围问题?
时间戳,用10位来标记的,1664366228,是此刻的发贴时间,能表示的最大数的范围是100亿,100亿秒也就是317年啊。。。。。这种时间戳317年后咋办? 我哪里有没有算错? 一般不是按多少位数字吧,一般是4个字节或者8个字节,你做什么样的产品需要考虑300多年后的事情? 电脑从发明到现在还不到100年,你已经在想317年之后的事情了,就不打算给曾曾曾孙子们留点事做么? {:lol:} 想当年年的表示才2位数,他们连100年都没有考虑到,你都考虑300年后的了? 留个彩蛋 yyts 发表于 2022-9-28 20:03一般不是按多少位数字吧,一般是4个字节或者8个字节,你做什么样的产品需要考虑300多年后的事情? ...
(引用自3楼)
说来惭愧,一不是做产品,二也不是考虑300年后的事,而是就事论事,讨论这个时间戳“技术”而已。。。。。 INT32_MAX = 2147483647 -> 2038-01-19 11:14:07
UINT32_MAX = 4294967295 -> 2106-02-07 14:28:15
不能按十进制的位数来算,用 32-bit 类型存储的,很快就要遇到问题了
另外由于 1970 年之前的时间戳是负数,所以一般时间戳也不会用无符号数存储
wudicgi 发表于 2022-9-28 21:25
INT32_MAX = 2147483647 -> 2038-01-19 11:14:07
UINT32_MAX = 4294967295 -> 2106-02-07 14:28:15
(引用自8楼)
您上面描述的都对,明显带有硬件工程师的痕迹。。。。{:titter:}
虽然没有说到点上,但提醒了我的思路,目前来看,10位可以使用300多年之久,如果300多年过去,10位溢出,会用到11位,依此类推,会达到2^64,这个数有千万年之久,足以用到地球的末日。。。 本帖最后由 redroof 于 2022-9-28 22:35 编辑
wudicgi 发表于 2022-9-28 21:25
INT32_MAX = 2147483647 -> 2038-01-19 11:14:07
UINT32_MAX = 4294967295 -> 2106-02-07 14:28:15
(引用自8楼)
除了最新版本之外,稍微旧一点的32位linux,系统时间都是这样的,到2038年就记满要绕回了。
从现在起还有16年而已,我们都还没退休呢。。。
不知道在十年后,那些32位的linux系统是不是全淘汰光了。否则如果那个时候新卖岀的产品,在它的设计寿命内真的会遇到2038年 最近搞定时启停,才发现....每周7天....从未缺失!所以只设计7天的算法......哈哈 别管多少年....反正7天设定对即可! 32位的时间戳目前够用,头疼的是闰秒问题,尤其是不能远程升级的设备。
现在公司产品通信协议里虽然有时间戳,但服务器没做校验。 我的STM32代码调用 time.h中的函数,根据RTC时间计算unix time,不知为何总需要减去8小时才对 本帖最后由 redroof 于 2022-9-28 22:54 编辑
Doding 发表于 2022-9-28 22:38
32位的时间戳目前够用,头疼的是闰秒问题,尤其是不能远程升级的设备。
现在公司产品通信协议里虽然有时间 ...
(引用自13楼)
闰秒有什么问题?
再好的RTC一年也要差到分钟级别。完全不联网的设备,肯定得设计让用户自己调时间,也不缺这平均几年一个闰秒。
联网的从服务器校时就行了,服务器的时间要准确是很容易的。 modu8888 发表于 2022-9-28 22:48
我的STM32代码调用 time.h中的函数,根据RTC时间计算unix time,不知为何总需要减去8小时才对...
(引用自14楼)
因为中国是+8时区啊,变成UTC要减8 MSDN 上关于 time( ) 和 time64( ) 函数的额外说明。显然 32bit 就是 31bit 有效计数范围,64bit 就是强制到一千年以后...
预计十几年后,会集中爆发一批比 2k 还大的千年虫
2038年是一个很大的问题 所以我的时间戳都是用64bit来做的,这样我的子孙们不会因为这个问题把我从坟墓里面骂出来 redroof 发表于 2022-9-28 22:53
闰秒有什么问题?
再好的RTC一年也要差到分钟级别。完全不联网的设备,肯定得设计让用户自己调时间,也不 ...
(引用自15楼)
奇怪的是,松下电饭锅,买回来3年多了,现在还不差不一分钟,松下用的什么黑科技? 本帖最后由 Doding 于 2022-9-29 10:21 编辑
redroof 发表于 2022-9-28 22:53
闰秒有什么问题?
再好的RTC一年也要差到分钟级别。完全不联网的设备,肯定得设计让用户自己调时间,也不 ...
(引用自15楼)
我两件事放一起了。
设备从服务器读历史记录,得服务器排好序,防止万一有时间一样的,不能只带UTC时间,其他有没有闰秒到没什么问题。
遇到过奇葩的客户需求,定时启动要求精确到秒,还要时间准,客户会拿手机和设备对时间准不准,因为客户定时同一个时间启动,几百台风机一起启动会跳闸,就自己想了这么个解决方法,我说给风机延时随机秒数启动,客户说什么都不同意,就是要能精确到秒他自己调,最后每半小时同步一次时间客户才验收。后来销售说其他客户也要这样做。。。
服务器那个,有时候设备NTP连不上,用RTC时间,RTC调到什么时间的都有,服务器只能判断同一IP有没有大量同一个时间戳请求,没办法判断准不准了。 Doding 发表于 2022-9-29 09:25
我两件事放一起了。
设备从服务器读历史记录,得服务器排好序,防止万一有时间一样的,不能只带UTC时间 ...
(引用自21楼)
设备默认用自己的时间啊,一天总差不到哪里。每天半夜1-3点随机时间,设备和服务器对一下时,就可以消掉RTC的长期误差。设备和你的服务器用你自己的协议对时就行。
你的服务器找个可靠的ntp来对时
xmlbb 发表于 2022-9-29 09:24
奇怪的是,松下电饭锅,买回来3年多了,现在还不差不一分钟,松下用的什么黑科技? ...
(引用自20楼)
应该是你运气好,然后电饭锅放在厨房,冬天也不会冷多少,夏天不会热多少。
卡西欧的电子表很容易达到你按ppm计算会感觉不可思议的精度,前提条件就是你常年戴着它。原因是厂家就按它戴在手上的那个温度来校准的温漂的。人的体温非常恒定。 redroof 发表于 2022-9-29 10:26
设备默认用自己的时间啊,一天总差不到哪里。每天半夜1-3点随机时间,设备和服务器对一下时,就可以消掉R ...
(引用自22楼)
服务器做过对时,不知道是设备程序的问题,还是服务器程序的问题,总有部分设备同步到的时间是错的,没人分析过什么原因,就被领导统一规定设备连NTP对时,就有连不上的情况了,服务器对时可以试很多地址,设备换地址试要写程序,嫌麻烦没人做。各种奇葩事我真是看不下去了,已经提了离职,明天最后一天。
客户的各种奇怪的需求,销售照单全收,也不考虑是否合理,就要求研发按需求做,做完了发现不是客户想要的,再改,补丁摞补丁。
页:
[1]