CC1310: RTC计时是否会遇到时间虫问题。

您好，

这个问题我将咨询一下更了解这个版本 SDK 的 E2E 工程师，请等候一下。

也就是说，cc1310在计时到2038年后，时间也会溢出，系统时间会错乱？

是的，芯片使用的是标准的 32 位无符号整数来表示时间，那么的确会存在2038年的问题：https://software-dl.ti.com/lprf/simplelink_cc26x2_sdk-1.60/docs/tirtos/sysbios/docs/cdoc/ti/sysbios/hal/Seconds.html

那有什么解决方法吗，自己去计算时间，还是把SDK内的源码更改？

正在跟进如何解决此问题的方法，您也可以关注一下回复：https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1325975/cc1310-will-rtc-timing-encounter-year-2038-problems

我看你们SDK里面是从寄存器里读出从1970年开始的秒数，但是在计算的时候补上了1900-1970的70年的秒数，1900年开始计算的，这样的话32位的秒最大只有136年左右。到2036年就出问题了。这对于我这种需要使用时间戳转换的应用来说，是会有问题的。我觉得你们可以增加一个宏定义（或者你们已经有了这个？），一个是从1900年开始计算，一个是从1970年开始计算，这样就可以解决。

为什么解决不了？我看你们SDK里面获取秒的API写着从1970年开始。只是后面增加了1900-1970的秒数，而且这里有个__ti__的宏定义（不知道这个宏是针对哪些应用的）。

那不是可以不补偿这70年，而是直接用从1970开始的秒数，去计算当前的时间吗？32位变量138年，应该也可以记到2100多年吧，还是说我哪里有理解上的错误？

我认为2038发行时间是从1970年1月1日开始计算的，不存在补偿问题。

Yolande Wang 说：

是的，芯片使用的是标准的 32 位无符号整数来表示时间，那么的确会存在2038年的问题：https://software-dl.ti.com/lprf/simplelink_cc26x2_sdk-1.60/docs/tirtos/sysbios/docs/cdoc/ti/sysbios/hal/Seconds.html

抱歉造成了混乱。

SDK代码使用uint 32无符号整数，应该可以使用到 1970 + 136  = 2106 年，因此 2038 年不会出现时间溢出。

所以您放心使用。

我测试过，使用你们的API确实有溢出问题，你看我从你们SDK的代码截图，这个t是32位的，加上了1900-1970年内间的秒数，超过2038年就溢出了。我尝试过写入Seconds_set一个2040年，确实有问题。所以我当初看到SDK里的源码的时候，这个__ti__宏定义是不是已经考虑到了两种起始时间（1900/1970）。我也试过把这个宏定义注释掉，似乎没什么效果。

所以要么就自己去实现了，拿这个t去计算从1970年开始的时间戳。我只是想看看SDK内部是否实现了，这样我就可以不用去手动计算。

这里需要区分一下有符号整数和无符号整数所产生的影响。如果使用 unix 有符号的 32 位 int 来存储它，则会出现溢出。

32 位有符号整数的最大值是 2 ³¹ − 1 ，当时间戳超过这个值（2038 年 1 月 19 日 03:14:07 UTC）时，将溢出导致时间错误。

而 uint 32 类型，即 32 位无符号整数，最大值是   2 ³² − 1，这能将最后时间延长到 2106 年。从您截取的代码来看，使用的是无符号整型，所以2038年不会出现时间溢出。