[参考译文] CC1310：RTC 计时是否会遇到2038年问题？

admin

Other Parts Discussed in Thread: SYSBIOS, CC1310

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

器件型号：CC1310
Thread 中讨论的其他器件：SYSBIOS、

大家好、

客户使用 simplelink_cc13x0_sdk_4_20_02_07中的 seconds_set API 来设置系统时间、然后使用本地时间获取年、月、日和其他信息。此 SDK 是否解决了2038年的问题？

谢谢！此致！

约兰德

1 年多前

0 admin 1 年多前

TI__Guru**** 2478765 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

不,我不这么认为。如果您在 SDK 中的 C：\ti_simplelink_cc13x0_sdk_4_20_02_07\kernel\tirtos\packages\ti\sysbios\fale\arm\msp432文件中、实际上会出现警告：

/*
 *  ======== 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)中不存在相同的警告

但我认为这并不意味着这在这里不是问题，只是没有警告。

Siri

0 admin 1 年多前

TI__Guru**** 2478765 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

你好，Siri，ć

感谢您的答复。

但我想知道如何避免这个问题。

此致、

约兰德

0 admin 1 年多前

TI__Guru**** 2478765 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您无法避免该问题。

如果使用 UNIX 时间并使用带符号的32位整数来存储它、则会出现溢出。

参见年2038问题-维基百科 ,自由的百科全书。

如果此溢出对您的系统而言是否严重、我想取决于您使用的时间和日期。

如果你只是有一些东西只是要显示当前时间,你可以做某种检查代码,看看数据是否已换行(时间突然出现在 00 : 00:00 UTC 在 1970年1月1日), 然后对其进行某种补偿。

很抱歉，我不能为您提供任何解决办法。

Siri

0 admin 1 年多前

TI__Guru**** 2478765 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

你好，Siri，ć

客户表示：

SDK 从寄存器中读取从1970年开始的秒数、但在计算时、添加1900至1970年之间的秒数、并且计算始于1900年。在这种情况下、32位秒的最大值仅为136年。关于。到2036年将出现问题。对于像我这样需要时间戳转换的应用程序而言、这会有问题。我想您可以添加一个从1900年开始、一个从1970年开始的宏定义(或者您是否已经有这个定义？)、以便能够解决这个问题。

此致、

约兰德

0 admin 1 年多前

TI__Guru**** 2478765 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

正如我所说，我们没有解决这一问题的办法，我认为也没有计划对此作出任何修正。

我认为、在我们使用 RTOS 7 (CC13x2 SDK)的较新器件上、此问题可能已通过使用64位而不是32位进行了修复、但没有计划针对 CC1310进行 SDK 更新。

0 admin 1 年多前

TI__Guru**** 2478765 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

尊敬的 Siri：

客户认为可以通过修改代码来解决：

是否可能不补偿这70年、而是直接使用从1970年开始的秒来计算当前时间？ 32位变量138年、它应该能够记住2100多年、或者我的理解中有什么错误吗？

_ti__有一个宏定义(我不知道这个宏用于什么应用)：

此致、

约兰德

0 admin 1 年多前

TI__Guru**** 2478765 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

你好，Siri，

2038年的发行时间是从1970年1月1日开始计算的，没有赔偿问题。 SDK 代码使用 uint 无符号整数、此整数应能够在2106之前使用、因此2038年没有时间溢出。我是否理解正确？

此致、

约兰德

0 admin 1 年多前

TI__Guru**** 2478765 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

CC1310 SDK 使用32位变量、会在2036年02月07日06：28：15中遇到问题。

会发生溢出、如下所述/说明：

第2038年-维基百科,自由的百科

也许可以在应用中解决这个问题、客户也可以随意尝试在实现中修复这个问题、但我将无法提供关于如何做到这一点的任何更多指导和/或示例代码。

如果客户认为自己有一个解决方案、他只需要尝试以某种方式进行测试。

很抱歉、我无法就此主题提供更多帮助。

Siri

低于 1GHz（参考译文帖）

低于 1GHz（参考译文帖）(Read Only)

[参考译文] CC1310：RTC 计时是否会遇到2038年问题？