嵌入式linux开发,为什么 Yocto 编译要强制用 UTC

问题

在构建版本信息时，发现由yocto编译uboot时，生成的时间信息，与实际使用的不一样

而实际上时间应该是上午10点

分析

为什么yocto编译要用 UTC？

The TZ environment variable is set to “UTC” within the build environment in order to fix reproducibility problems in some recipes.

https://docs.yoctoproject.org/4.0.33/migration-guides/migration-2.5.html

从Yocto 官方文档，结合实际情况，可以得出如下3点：

1. 1. 可复现构建（Reproducible Builds）Yocto 的目标是：同一份配置、同一份源码，在任何时间、任何机器上构建出来的二进制文件要完全一样。如果构建过程里嵌入时间信息（例如打包时间、日志时间），且这些时间受时区影响，就会导致同一份源码在不同机器上构建出不同内容。
2. 2. 统一时间基准在构建环境中强制 TZ=UTC，相当于告诉所有工具：不要按本地时区解释当前时间， 所有时间都以 UTC 输出和存储，这样，无论在北京（UTC+8）还是伦敦（UTC+0），构建产物中嵌入的时间戳都是同一数值。达到跨时区的一致性
3. 3. 标准化要求：yocto作为嵌入式开源项目，采用UTC 作为无偏移的基准时间，避免时区配置错误导致的日志、任务调度、文件时间等混乱，同时也符合行业默认标准。

所以：看到的“Yocto 编译采用 UTC”，本质上是为了让构建过程可复现、可对比、可溯源、标准化

扩展

那么除了UTC还有那些和时间有关的概念呢？

3.1 UTC

UTC，即（Coordinated Universal Time），世界协调时间，是当前国际通用的时间标准。

• • 以原子时为基础，通过闰秒修正，
• • 所有官方时区都以“相对 UTC 的偏移”来定义，例如北京时间 = UTC+8

3.2 GMT

GMT，即（Greenwich Mean Time），格林尼治时间，曾经的世界“时间标准”，

• • 通过格林尼治天文台的本初子午线定义平太阳时。
• • 现在 GMT 更多被当作一个时区名（UTC+0），而不是严格的时间标准

很多人把 GMT 当成“标准时间”，实际在现代时间标准体系中，UTC 才是官方标准

3.3 CST

CST ,（China Standard Time）,中国标准时间,

• • “北京时间”，CST = UTC+8

3.4 Unix epoch

Unix epoch（Unix 纪元），即Unix 时间戳，它是指从 1970-01-01 00:00:00 UTC 开始，到某个时刻所经过的秒数

• • 是Unix/Linux 系统中时间戳的起始点
• • 数值线性增长，每增加 1 秒，时间戳 +1。
• • 与时区无关，同一时刻，全球任何地方看到的 Unix 时间戳数值相同。
• • 2026-03-05 12:30:45 UTC 的秒级时间戳：2138401845

有意思的2038 年问题，早期 32 位 time_t 用有符号 32 位整数存时间戳，最大只能表示到 2038-01-19 左右，之后会溢出“回到” 1901 年，现在主流 64 位系统已经用 64 位 time_t，基本解决该问题。

https://www.epochconverter.com/https://www.unixtimestamp.com/

3.5 ISO-8601

时间戳都是一串数字，对于人来说非常不好读的，因此需要有一个标准，将时间戳转换成可读的统一时间标准，其中之一就是ISO-8601标准

• • 核心是 “清晰、无歧义、机器可读”
• • 它的格式按 “年 - 月 - 日 - T - 时：分: 秒 - 时区” 的固定顺序，如2025-01-28T10:00:00

有时也会看到：带 UTC 时区：2025-01-28T10:00:00Z，或带时区偏移：2025-01-28T18:00:00+08:00

总结

• • UTC 是全球统一的时间基准，Yocto 用 UTC 是为了跨时区编译的一致性，GMT 是历史基准，已被 UTC 取代；
• • CST 是本地时区，ISO 8601 是时间表示标准（无歧义），Unix epoch 是时间戳的起始点（1970-01-01 UTC）；
• • 在在跨时区、跨系统的开发中，用 UTC 做底层基准，用 ISO 8601 做格式交互，用时间戳做数值计算，能彻底避免时间相关的歧义问题。