dianzichina 发表于 2022-9-28 20:01:05

讨论一下时间戳的范围问题？

时间戳，用10位来标记的，1664366228，是此刻的发贴时间，能表示的最大数的范围是100亿，100亿秒也就是317年啊。。。。。这种时间戳317年后咋办？

dianzichina 发表于 2022-9-28 20:01:47

我哪里有没有算错？

yyts 发表于 2022-9-28 20:03:56

一般不是按多少位数字吧，一般是4个字节或者8个字节，你做什么样的产品需要考虑300多年后的事情？

gzhuli 发表于 2022-9-28 20:09:08

电脑从发明到现在还不到100年，你已经在想317年之后的事情了，就不打算给曾曾曾孙子们留点事做么？ {:lol:}

1a2b3c 发表于 2022-9-28 20:15:38

想当年年的表示才2位数，他们连100年都没有考虑到，你都考虑300年后的了?

Flyback 发表于 2022-9-28 20:25:13

留个彩蛋   

dianzichina 发表于 2022-9-28 21:19:16

yyts 发表于 2022-9-28 20:03
一般不是按多少位数字吧，一般是4个字节或者8个字节，你做什么样的产品需要考虑300多年后的事情？ ...
(引用自3楼)

说来惭愧，一不是做产品，二也不是考虑300年后的事，而是就事论事，讨论这个时间戳“技术”而已。。。。。

wudicgi 发表于 2022-9-28 21:25:34

INT32_MAX = 2147483647 -> 2038-01-19 11:14:07
UINT32_MAX = 4294967295 -> 2106-02-07 14:28:15

不能按十进制的位数来算，用 32-bit 类型存储的，很快就要遇到问题了

wudicgi 发表于 2022-9-28 21:28:39

另外由于 1970 年之前的时间戳是负数，所以一般时间戳也不会用无符号数存储

dianzichina 发表于 2022-9-28 22:16:13

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:16:41

本帖最后由 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年

liao-ljj 发表于 2022-9-28 22:30:54

最近搞定时启停，才发现....每周7天....从未缺失！所以只设计7天的算法......哈哈   别管多少年....反正7天设定对即可！

Doding 发表于 2022-9-28 22:38:31

32位的时间戳目前够用，头疼的是闰秒问题，尤其是不能远程升级的设备。
现在公司产品通信协议里虽然有时间戳，但服务器没做校验。

modu8888 发表于 2022-9-28 22:48:57

我的STM32代码调用 time.h中的函数，根据RTC时间计算unix time，不知为何总需要减去8小时才对

redroof 发表于 2022-9-28 22:53:34

本帖最后由 redroof 于 2022-9-28 22:54 编辑

Doding 发表于 2022-9-28 22:38
32位的时间戳目前够用，头疼的是闰秒问题，尤其是不能远程升级的设备。
现在公司产品通信协议里虽然有时间 ...
(引用自13楼)

闰秒有什么问题？
再好的RTC一年也要差到分钟级别。完全不联网的设备，肯定得设计让用户自己调时间，也不缺这平均几年一个闰秒。
联网的从服务器校时就行了，服务器的时间要准确是很容易的。

redroof 发表于 2022-9-28 22:56:22

modu8888 发表于 2022-9-28 22:48
我的STM32代码调用 time.h中的函数，根据RTC时间计算unix time，不知为何总需要减去8小时才对...
(引用自14楼)

因为中国是+8时区啊，变成UTC要减8

t3486784401 发表于 2022-9-28 23:03:35

MSDN 上关于 time( ) 和 time64( ) 函数的额外说明。显然 32bit 就是 31bit 有效计数范围，64bit 就是强制到一千年以后...

预计十几年后，会集中爆发一批比 2k 还大的千年虫

qwe2231695 发表于 2022-9-29 01:42:48

2038年是一个很大的问题

dellric 发表于 2022-9-29 09:19:48

所以我的时间戳都是用64bit来做的，这样我的子孙们不会因为这个问题把我从坟墓里面骂出来

xmlbb 发表于 2022-9-29 09:24:14

redroof 发表于 2022-9-28 22:53
闰秒有什么问题？
再好的RTC一年也要差到分钟级别。完全不联网的设备，肯定得设计让用户自己调时间，也不 ...
(引用自15楼)

奇怪的是，松下电饭锅，买回来3年多了，现在还不差不一分钟，松下用的什么黑科技？

Doding 发表于 2022-9-29 09:25:02

本帖最后由 Doding 于 2022-9-29 10:21 编辑

redroof 发表于 2022-9-28 22:53
闰秒有什么问题？
再好的RTC一年也要差到分钟级别。完全不联网的设备，肯定得设计让用户自己调时间，也不 ...
(引用自15楼)

我两件事放一起了。

设备从服务器读历史记录，得服务器排好序，防止万一有时间一样的，不能只带UTC时间，其他有没有闰秒到没什么问题。

遇到过奇葩的客户需求，定时启动要求精确到秒，还要时间准，客户会拿手机和设备对时间准不准，因为客户定时同一个时间启动，几百台风机一起启动会跳闸，就自己想了这么个解决方法，我说给风机延时随机秒数启动，客户说什么都不同意，就是要能精确到秒他自己调，最后每半小时同步一次时间客户才验收。后来销售说其他客户也要这样做。。。

服务器那个，有时候设备NTP连不上，用RTC时间，RTC调到什么时间的都有，服务器只能判断同一IP有没有大量同一个时间戳请求，没办法判断准不准了。

redroof 发表于 2022-9-29 10:26:16

Doding 发表于 2022-9-29 09:25
我两件事放一起了。

设备从服务器读历史记录，得服务器排好序，防止万一有时间一样的，不能只带UTC时间 ...
(引用自21楼)

设备默认用自己的时间啊，一天总差不到哪里。每天半夜1-3点随机时间，设备和服务器对一下时，就可以消掉RTC的长期误差。设备和你的服务器用你自己的协议对时就行。
你的服务器找个可靠的ntp来对时

redroof 发表于 2022-9-29 10:31:23

xmlbb 发表于 2022-9-29 09:24
奇怪的是，松下电饭锅，买回来3年多了，现在还不差不一分钟，松下用的什么黑科技？ ...
(引用自20楼)

应该是你运气好，然后电饭锅放在厨房，冬天也不会冷多少，夏天不会热多少。
卡西欧的电子表很容易达到你按ppm计算会感觉不可思议的精度，前提条件就是你常年戴着它。原因是厂家就按它戴在手上的那个温度来校准的温漂的。人的体温非常恒定。

Doding 发表于 2022-9-29 10:38:36

redroof 发表于 2022-9-29 10:26
设备默认用自己的时间啊，一天总差不到哪里。每天半夜1-3点随机时间，设备和服务器对一下时，就可以消掉R ...
(引用自22楼)

服务器做过对时，不知道是设备程序的问题，还是服务器程序的问题，总有部分设备同步到的时间是错的，没人分析过什么原因，就被领导统一规定设备连NTP对时，就有连不上的情况了，服务器对时可以试很多地址，设备换地址试要写程序，嫌麻烦没人做。各种奇葩事我真是看不下去了，已经提了离职，明天最后一天。
客户的各种奇怪的需求，销售照单全收，也不考虑是否合理，就要求研发按需求做，做完了发现不是客户想要的，再改，补丁摞补丁。
页: [1]
查看完整版本: 讨论一下时间戳的范围问题？