[参考译文] LAUNCHXL-CC26X2R1：__ TI_TIME_USES_64我们是否需要它？：)

admin

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

器件型号：LAUNCHXL-CC26X2R1

大家好！

我们的固件应用程序使用的是 seconds_set ()和 seconds_get () API，没有使用 __TI_time_uses_64。

从现在开始,到2038年,什么是 seconds_get ()将返回?

我知道我们可以在某个位置添加偏移来考虑不是1900年、而是较新的基准时、但我不认为这是最巧妙的解决方案。

我们是否需要使用 __ TI_TIME_USES_64来更新我们的软件和固件？

请像我五岁一样解释、因为时间问题非常抽象。

祝你度过美好的一天！

0 admin 1 年多前

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

您好！

您选择的实现方式将取决于如何在系统中使用 seconds_get 的时间戳。

bo shi2 说：
到现在为止,到2038年,什么是 seconds_get ()将返回?

如果时间值递增、超过底层变量可保持的位数、则会发生回滚、并从基础时间开始(应用程序已通过 seconds_setTime 设置该时间)。

bo shi2 说：
我知道我们可以在某个位置添加偏移以考虑不是1900而是较新的作为基准时,但我不认为这是最优雅的解决方案。

从本地角度来看、我认为这是一个不错的选择。如果系统中有某种外部时间服务器、则可以打开选项。

bo shi2 说：
我们是否需要使用 __TI_time_uses_64并更新我们的软件和固件？

话虽如此、__TI_TIME_USES_64也是一个选项、但采用该选项时、您需要考虑系统中的所有其他器件。例如、如果系统中的其他一些器件仅支持32位时间、并且这一次从 CC26xx 传递给它、则可能会有问题。

根据系统中使用时间戳的方式、我认为一致性是最重要的考虑因素之一。

谢谢。
托比

0 admin 1 年多前

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

大家好，托比 P

感谢您的观看和回答。

在当前的 SDK 中,seconds_get ()返回 uint32_t ,因此到2038年似乎就会出现问题。如果我理解错了、请告诉我。

只是最后一个问题,所以当它回滚时,它不是从0开始,而是在以前设置的值为 seconds_set()?

0 admin 1 年多前

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

似乎今年2038错误只影响使用签名 int32_t 作为其数据时间的系统。使用 uint32_t 似乎可以摆脱它。我做了一个测试,似乎我们被涵盖到2106。

谢谢。如果我理解错误、请告诉我。将该主题标记为已解决。

Bluetooth®︎（参考译文帖）(Read Only)