TI中文支持网Part Number:CC1310Other Parts Discussed in Thread:SYSBIOS,
我使用simplelink_cc13x0_sdk_4_20_02_07里面的Seconds_set这一API来设置系统时间，再通过localtime来获取年月日等信息，请问这个SDK内部是否已经处理过时间虫问题？例如2038年时间虫问题。
Yolande Wang：
您好，
这个问题我将咨询一下更了解这个版本 SDK 的 E2E 工程师，请等候一下。
,
Yolande Wang：
非常抱歉，查看 SDK 中的 C:\ti\simplelink_cc13x0_sdk_4_20_02_07\kernel\tirtos\packages\ti\sysbios\family\arm\msp432 下的 Seconds.c 文件，实际上有一个警告：
/**======== Seconds_get ========**Note: This function is only valid until 2036-02-07 06:28:15 (TI Compiler)*or 2038-01-19 03:14:07(GNU, IAR Compilers). At this time the number*of seconds since 1900/1970 will cause integer overflow on 32-bit*systems.*/CC26xx 的 Seconds.c 文件中不存在相同的警告 (C:\ti\simplelink_cc13x0_sdk_4_20_02_07\kernel\tirtos\packages\ti\sysbios\family\arm\cc26xx)
但我不认为意味着这不是问题，只是缺少警告。
您可以点击此链接查看回复：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/5045403#5045403
,
o.O?：
也就是说，cc1310在计时到2038年后，时间也会溢出，系统时间会错乱？
,
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
,
o.O?：
那有什么解决方法吗，自己去计算时间，还是把SDK内的源码更改？
,
Yolande Wang：
正在跟进如何解决此问题的方法，您也可以关注一下回复：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
,
Yolande Wang：
以下是来自E2E的回复：
无法避免这个问题。
如果使用 unix 时间使用有符号的 32 位 int 来存储它，则会出现溢出。
有关详细信息，请参阅 Year 2038 problem – Wikipedia 。
如果此溢出对于您的系统至关重要或不重要，我想这取决于您使用时间和日期的目的。
如果您只是要显示当前时间，您也可以在代码中进行某种检查，看看数据是否已换行（时间突然出现 在 1970 年 1 月 1 日 00:00:00 UTC 之前） ），然后对此进行某种补偿。
很抱歉，我无法为您提供任何解决方案。
,
o.O?：
我看你们SDK里面是从寄存器里读出从1970年开始的秒数，但是在计算的时候补上了1900-1970的70年的秒数，1900年开始计算的，这样的话32位的秒最大只有136年左右。到2036年就出问题了。这对于我这种需要使用时间戳转换的应用来说，是会有问题的。我觉得你们可以增加一个宏定义（或者你们已经有了这个？），一个是从1900年开始计算，一个是从1970年开始计算，这样就可以解决。
,
Yolande Wang：
正在跟进问题，有进展立即回复您。
,
Yolande Wang：
来自E2E的回复：
我们对此没有解决方案，而且也没有计划对此进行修复。
我认为在我们使用 RTOS 7 (CC13x2 SDK) 的较新设备上，可能已经使用 64 位而不是 32 位，从而修复了这个问题，但没有计划针对 CC1310 进行 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/5054395#5054395
,
o.O?：
为什么解决不了？我看你们SDK里面获取秒的API写着从1970年开始。只是后面增加了1900-1970的秒数，而且这里有个__ti__的宏定义（不知道这个宏是针对哪些应用的）。
那不是可以不补偿这70年，而是直接用从1970开始的秒数，去计算当前的时间吗？32位变量138年，应该也可以记到2100多年吧，还是说我哪里有理解上的错误？
,
Yolande Wang：
我认为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 年不会出现时间溢出。
所以您放心使用。
,
o.O?：
我测试过，使用你们的API确实有溢出问题，你看我从你们SDK的代码截图，这个t是32位的，加上了1900-1970年内间的秒数，超过2038年就溢出了。我尝试过写入Seconds_set一个2040年，确实有问题。所以我当初看到SDK里的源码的时候，这个__ti__宏定义是不是已经考虑到了两种起始时间（1900/1970）。我也试过把这个宏定义注释掉，似乎没什么效果。
所以要么就自己去实现了，拿这个t去计算从1970年开始的时间戳。我只是想看看SDK内部是否实现了，这样我就可以不用去手动计算。
,
Yolande Wang：
这里需要区分一下有符号整数和无符号整数所产生的影响。如果使用 unix 有符号的 32 位 int 来存储它，则会出现溢出。
32 位有符号整数的最大值是 2 31 − 1 ，当时间戳超过这个值（2038 年 1 月 19 日 03:14:07 UTC）时，将溢出导致时间错误。
而 uint 32 类型，即 32 位无符号整数，最大值是 2 32 − 1，这能将最后时间延长到 2106 年。从您截取的代码来看，使用的是无符号整型，所以2038年不会出现时间溢出。
