准确显示时间是车载信息娱乐系统的一项核心预期功能。虽然这看起来可能非常简单（尤其是在对时间和时区管理的期望较低且必须满足时），但当必须在没有人工干预的情况下可靠地准确显示日期和时间时，时间很快就会变得复杂。
所有片上系统 (SoC) 中常用的实时时钟通常都包含一些漂移，这些漂移会随着时间的推移而累积，如果不对其进行校正，可能会导致明显的误差。此外，由于人们期望准确显示当地时间，因此必须考虑与协调世界时 (UTC) 的正确偏移量。
时区信息以及夏令时 (DST) 的应用预计会在车辆的预期寿命内发生变化。例如，巴西在实施夏令时多年后，选择在 2019 年不启动夏令时计划。
Android 提供了协商时区规则管理复杂性所需的基础架构。如需了解详情，请参阅时区规则，OEM 可以使用该规则将更新的时区规则数据推送到设备，而无需系统更新。此机制支持
- 用户及时接收更新（从而延长 Android 设备的有用寿命）。
- OEM 独立于系统映像更新来测试时区更新。
注意：AAOS 10 不支持 Android 10（及更高版本）发行版中提供的基于 APEX 的模块更新机制。
注意：要实现此机制，需要重启系统。
汽车中的时间（时区）信息来源
Android 设备在系统级别以 Unix 时间管理时间，应用所需的时区偏移量，然后将该值转换为本地时间以显示给用户。当前用户的时区 ID（通常称为 Olson ID）作为设置存储。例如，Europe/London。
下面概述的许多机制都描述了时间信息。这些标准的目的是为用户提供当前时间，而不是描述适用的时区规则。要确定实际时区，设备必须从国家/地区、偏移量和夏令时偏移量等因素反向推导，然后再设置时区 ID。
这个过程可能具有挑战性。基于可用信息进行反向推导可能存在歧义。例如，America/Denver 时区规则遵循夏令时，但在夏季采用山区夏令时间 (MDT)，而 America/Phoenix 时区规则继续识别 MDT。
蜂窝无线
系统信息 (SI) 是长期演进 (LTE) 空中接口的重要组成部分，它由基站 (BS) 通过广播控制信道 (BCCH) 传输。3GPP TS 36.331 规范指定了 SystemInformationBlockType16 (SIB16)，其中包含与 GPS 和协调世界时 (UTC)、本地时间偏移以及夏令时信息相关的信息。
在 2G 和 3G 中可以找到类似的功能，在 2G 和 3G 中，可以广播网络标识和时区 (NITZ) 信息（详情请参阅 3GPP TS 22.042）。其他蜂窝无线标准具有等效功能。
遗憾的是，大多数标准之间的共性是，此信息的发送是可选的，因此并非在所有网络上都普遍可用。
| 优点 | 缺点 |
|---|---|
|
|
网络时间协议
网络时间协议 (NTP) 通常用于获取相对精确的 Unix 纪元时间信息。如果可以通过通用 RadioTuner.getParameters() 元数据向 RadioManager 的客户端公开，则 Android 支持将其系统时间与 NTP 服务器的时间同步。当系统时间不同步且运营商最近未提供 NITZ 更新时，NTP 会更新系统时间。如果用户在 NITZ 不可用时启用 AUTO_TIME，系统会立即检查网络时间。
| 优点 | 缺点 |
|---|---|
|
简单性，Android 支持。 |
|
广播无线电调谐器
虽然利用内置调谐器检索时间和时区信息很有吸引力，但也存在挑战。许多无线电广播标准定义了公开所需信息的选项。一般来说，广播无线电调谐器提供与蜂窝无线电相同的信息。
ETSI EN 300 401 V1.4.1 (2006-06) 第 8.1 节 指定了服务信息功能，这些功能为数字音频广播 (DAB) 系统的音频节目和数据提供补充信息。第 8.1.3 节定义了时间和日期格式，以及国家/地区和当地时间偏移量的信息。
同样，对于 FM 调谐器中常用的无线电数据系统 (RDS)，EN 50067 标准的第 3.1.5.6 节定义了时钟时间和数据（每分钟传输一次）的格式。此外，扩展国家/地区代码 (ECC) 也可以作为传输节目识别的一部分进行检索。
高清无线电包含相应的选项，作为高清无线电™ 空中接口设计描述电台信息服务传输规范中电台信息服务 (SIS) 参数消息（MSG ID 0111）的一部分。第 5 节清楚地阐述了在尝试使用广播的时钟支持时必须注意的警示语。同样的智慧也同样适用于其他系统
| ... 这些数据描述了广播公司所在位置的当地习俗，这可能与接收器所在位置的当地习俗相同，也可能不同。在时区边界附近，消费者可能会收到多个电台提供不同的数据。因此，这些数据仅作为提示提供，其解释和利用应酌情决定，并受客户控制。..." |
此外，至少对于高清无线电而言，此信息的广播是可选的，不应完全依赖。
优点 缺点- 通常在不同的区域广播无线电标准中可用。
- 不需要互联网连接。
- Android 不支持开箱即用的此功能。
- 需要打开调谐器（至少偶尔在后台）才能可靠地检测信息。
-
可靠性取决于广播公司。
实施技巧
如果可以通过RadioManager 的客户端公开，则 Android 支持将其系统时间与 NTP 服务器的时间同步。建议的解决方案是利用供应商扩展功能。此功能的实现必须在硬件抽象层 (HAL) 中进行，之后可以通过通用 RadioTuner.getParameters() 方法向 RadioManager 的客户端公开。
为了使该解决方案保持稳健，此供应商扩展的使用者必须确定 HAL 支持该功能（不要假设其存在）。getParameters 调用的参数字符串必须组织清晰，以便在不同供应商之间实现明确的用法。例如，使用您组织的命名空间，并在前面加上适当的域，例如 com.me.timezoneTuner.currenttimezone。
考虑到信息事件驱动的性质，使用 RadioTuner.Callback.onParametersUpdated() 回调来接收此信息可能是有益的。如果此功能应该是可配置的，请在 setParameters 之上设计一组自定义例程。例如
com.me.timezoneTuner.currenttimezoneEvent.enable
全球导航卫星系统
全球导航卫星系统 (GNSS) 本身只能提供准确的时间信息和位置信息。
地理位置
解决此不便之处的方法是执行反向地理编码，并通过基于位置查找来确定国家/地区和时区。GNSS 是车辆中位置信息的显而易见（且质量最佳）的选择。Google 的 Time Zone API 提供了运行所需转换所需的一切。当然，需要互联网连接。在实施在线解决方案时，确保用户隐私必须是重中之重！需要征得用户同意接受数据使用费用（或不接受），并且必须请求用户同意。
为离线使用创建合适的解决方案是可行的。具有足够分辨率以准确确定国家/地区和时区的本地地图数据库可以安装到车辆的存储空间中。有了这个数据库，以及用于根据需要在适当位置更新时区（和国家/地区）信息的完全实现的策略，就可以根据从位置信息子系统获取的 GNSS 位置反向地理编码国家/地区/时区。
| 优点 | 缺点 |
|---|---|
|
|
通过蓝牙、Wi-Fi 或 USB 连接的手机
可以使用多种技术来利用用户的手机获取时间和时区数据。对于所有手机，都必须在手机和车载信息娱乐 (IVI) 系统上安装一对自定义应用和配套应用。然后可以在所需的间隔同步时间。例如，在建立连接时以及当手机检测到新的时区时。
一些支持蓝牙低功耗 (BLE) 的手机提供了通过 GATT Current Time 特征和Current Time Service Profile Specification 1.1 检索时间的选项。但是，此选项未涵盖足够大的市场细分，无法完全依赖。
| 优点 | 缺点 |
|---|---|
|
|
使用来源
每个设备供应商都必须确定要设置多高的标准，以及哪些用户旅程被认为最关键。只有清楚了解所需的关键用户体验，才能做出最佳决策。在大多数情况下，供应商必须考虑便利性和实施复杂性之间的权衡。
上面描述的每个选项都存在优点和缺点。例如，必须就偶发性时间显示不佳相比，可以接受多少弹性以及如何管理缺点做出关键的设计选择。一个完全自动化的解决方案，可以预期在所有场景下都能良好运行，但必须基于多种信息来源的组合。没有哪个单一选项可以提供 100% 的可用性。
手动配置选项作为临时后备方案易于执行，并且在实践中对于许多用户来说可能就足够了。