[参考译文] CC3220SF-LAUNCHXL：CC3220 2038 年

您好、

TI-CGT-ARM_20.2.5.LTS 与 LLVM 相比的 TIRTOS 编译器版本更旧。

如果我看一下代码、您是对的、旧版编译器使用 32 位计时器、因此您确实可以发行 2038 年期。

最好的方法是改用基于 LLVM 的编译器（TI 宣布旧版 TIRTOS 已停产）。 较新的版本使用 64 位进行时间计算。

这是代码中的行：

#if defined (__CLANG__)&& defined (__TI_TIME_USES_64)&&__TI_TIME_USS_64

code_access __time64_t __time64 (__time64_t *_timer)

Shlomi

嗨、Shlomi、感谢您的回答。

如果我看一下代码、您是对的、旧版编译器使用的是 32 位计时器、因此您确实可以在 2038 年发布。

对不起 Shlomi,最后一封邮件是在它完成之前发送的;)

如果我看一下代码、您是对的、旧版编译器使用的是 32 位计时器、因此您确实可以在 2038 年发布。

但是、TI 在内部使用`uint32_t`可能也可以解决该问题。 这可能是注释“您可能有...“的原因。 我问道、因为我想避免编译器开关触发的大量发布阶段。

您能告诉我 Uint32 的内部使用是否解决了 2038 年的问题吗？

非常感谢、
罗马

您好、

我将需要再看一下,但虽然它被设置为无符号,因此得到一个额外的位使用,仍然,参考是年 1900 年,而不是年 1970 因此 136 年计数开始的时间早,因此应该绑定。

您提到了应用程序级别上的 time()。

对于主要用于日期的证书链验证、应用程序通过 SL_DEVICE_GENERAL_DATE_TIME 选项设置日期/时间、实际时间设置在 NWP 中完成。 我在内部检查了它,日期是可以与未来几年（没有限制）.

此致、

Shlomi

尊敬的 Shlomi：

再次感谢。

我需要再看一遍、但尽管它设置为无符号、因此需要额外使用一个位、但引用的年份是 1900 年、而不是 1970 年、因此 136 年的计数开始很早、因此应该绑定。

是的、由于它是最高有效位、因此计数器的大小可以是原来的两倍。 所以 1970 年的起点基本上是可能的。

您提到了应用程序级别上的 time()。

我使用我的日志记录系统的 time() 函数。
原则上、在时间同步对象（如队列）中使用此时间戳时、也存在 2028 问题。

我在内部进行了检查、日期可以在未来几年（无限制）。

我是否正确理解这一点:检查证书的有效期时没有 Y2028 问题?

此致、
罗马

您好、

TLS 堆栈是内部的、因此您需要正确设置时间和日期、以确保其可靠运行。

设置时间的方法是调用上面提到的 API。

因此、我所做的是随着年的增加（先设置，然后再设置）对其进行测试、可以很容易地看到 GET 按预期工作、并且我的 NWP 日志上打印了正确的日期。

至少对于证书、我们应该可以。

此致、

Shlomi

您好、Shlomy：

感谢您的回答。

因此、我所做的是随着年的增长（先设置，然后再获取）对其进行测试、可以很容易地看到 GET 按预期运行、并且正确的日期打印在我的 NWP 日志上。

  您在测试中使用了 simplelink_cc32xx_sdk_5_30_00_08 的 sp_3.21.0.1_2.7.0.0_2.2.0.7.bin、对吗？

此致、
罗马

您好、

实际上不是 我一直使用的是最新版本 3.22.x SP 和 SDK 7.10。

由于它与 SP 相关、并且由于它后面只有一个 SP、因此您应该可以。

Shlomi