The accurate display of time is a core feature expected of an automotive infotainment system. While this might appear deceptively simple, particularly when expectations of time and time zone management are low and must be met, time quickly becomes complex when a reliably accurate date and time must be displayed without manual intervention.
All real-time clocks typically used in system on chip (SoC) contain some drift, which accumulates over time and can lead to significant error when left uncorrected. In addition, because expectations are high that local time be displayed accurately, the correct offset from Coordinated Universal Time (UTC) must be considered.
Time zone information, as well as the application of Daylight Saving Time (DST), can be expected to change during the expected lifetime of a vehicle. For example, after many years of implementing DST, Brazil elected to not start a DST schedule in 2019.
Android provides the infrastructure needed to negotiate complications of time zone rule management. For details, see Time zone rules, which enables OEMs to push updated time zone rules data to devices without requiring a system update. This mechanism enables:
- Users to receive timely updates (which extend the useful lifetime of an Android device).
- OEMs to test time zone updates independently of system image updates.
Note: AAOS 10 doesn't support the APEX-based module update mechanism provided in releases of Android 10 (and higher).
Note: To implement this mechanism, a system reboot is required.
Time (zone) information sources in cars
Android devices manage time in Unix time at the system level, apply the desired time zone offset, and then convert the value to local time for display to users. The current user's zone ID (often referred to as Olson ID) is stored as a setting. For example, Europe/London.
Much of the mechanism outlined below describes time information. The intent of these standards is to provide users with the current time, not to describe the applicable time zone rules. To determine the actual time zone, the device must work back from factors such as country, offset, and DST offset prior to setting the zone ID.
The process can be a challenge. Working back based on available information can be ambiguous. For example, the time zone rule America/Denver observes DST but adopts to Mountain Daylight Time (MDT) during the summer whereas America/Phoenix continues to recognize MDT.
Cellular radio
System information (SI) is an essential aspect of the Long-Term Evolution (LTE) air interface, which is transmitted by the base station (BS) over the broadcast control channel (BCCH). 3GPP TS 36.331 specifies the SystemInformationBlockType16 (SIB16) which contains information related to GPS and Coordinated Universal Time (UTC), local time offset, as well as DST information.
Similar functionality can be found in 2G and 3G, where network identity and time zone (NITZ) information can be broadcast (see 3GPP TS 22.042 for details). Other cellular radio standards have equivalent features.
Unfortunately, the commonality among most standards is that the sending of this information is optional, so it isn't universally available on all networks.
| Pros | Cons |
|---|---|
|
|
Network time protocol
Network Time Protocol (NTP) is often used to obtain relatively precise Unix epoch time
information. Android supports the synchronization of its system time with that of an NTP server
if can be exposed to clients of
RadioManager through the generic
RadioTuner.getParameters() metadata. NTP updates the system time when it goes out of
sync and a carrier hasn't recently provided a NITZ update. If the user enables
AUTO_TIME when NITZ isn't available, the system checks immediately for network
time.
| Pros | Cons |
|---|---|
|
Simplicity, supported by Android. |
|
Broadcast radio tuner
While leveraging a built-in tuner to retrieve time and time zone information is appealing, challenges are involved. Numerous radio broadcast standards define options for exposing the desired information. Generally speaking, a broadcast radio tuner provides the same information as a cellular radio.
ETSI EN 300 401 V1.4.1 (2006-06), section 8.1 specifies service information features that provide supplementary information about services for both audio programme and data for Digital Audio Broadcasting (DAB) systems. Section 8.1.3 defines the format for time and date as well as information for country and local time offset.
Similarly, for the Radio Data System (RDS) commonly implemented in FM tuners, section 3.1.5.6 of the EN 50067 standard defines the format for clock-time and data (transmitted once per minute). In addition, the extended country code (ECC) can also be retrieved as part of the transmitted program identification.
HD Radio contains corresponding options as part of the HD Radio™ Air Interface Design Description Station Information Service Transport specification in the Station Information Service (SIS) Parameter Message (MSG ID 0111). Section 5 clearly spells out cautionary words that must be heeded when attempting to use the clock support of the broadcast. The same wisdom applies equally to other systems:
| ... these data describe the local custom at the location of the broadcaster, which may or may not be the same as the local custom at the place of the receiver. Near time-zone boundaries, consumers can receive a multiplicity of stations providing different data. Therefore, these data are provided only as hints, the interpretation and utilization of which should be made discretionary, subject to customer control. ..." |
In addition, for HD Radio at least, the broadcast of this information is optional and shouldn't be relied upon exclusively.
- Typically available across different regional broadcast radio standards.
- Does not require internet connectivity.
- Android doesn't support this out of box.
- Requires tuner to be turned on (at least occasionally in the background) to reliably detect information.
-
Reliability depends on the broadcaster.
Implementation tips
Android supports the synchronization of its system time with that of an NTP server if it can be exposed to clients ofRadioManager. The recommended solution is to leverage the vendor extension feature.
Implementation of this functionality must occur in the hardware abstraction layer (HAL), after which
if can be exposed to clients of RadioManager through the generic
RadioTuner.getParameters() method.
For the solution to remain robust, the consumer of this vendor extension must determine that the
HAL supports the feature (don't assume its existence). Parameter strings for the
getParameters call must be cleanly organized for unambiguous usage across vendors. For
example, using the namespace of your organization by prefixing it with the appropriate domain, for
example, com.me.timezoneTuner.currenttimezone.
Given the event-driven nature of the information, it can be beneficial to use the
RadioTuner.Callback.onParametersUpdated() callback for receiving this information. If
this facility should be configurable, design a set of custom routines on top of
setParameters. For example:
com.me.timezoneTuner.currenttimezoneEvent.enable
Global Navigation Satellite System
On its own, the Global Navigation Satellite System (GNSS) can provide only accurate time information and position.
Geolocation
The solution to this inconvenience is to execute reverse-geocoding and determine the country and time zone by doing a lookup based on position. GNSS is the obvious (and best quality) choice of location information in a vehicle. Google's Time Zone API offers all that's needed to run the required conversion. Of course, internet connectivity is required. Ensuring user privacy must be a top priority when implementing an online solution! The permission of a user to accept data usage costs (or not) is required and must be requested.
It's feasible to create a suitable solution for offline usage. A local map database with sufficient resolution to accurately determine the country and time zone can fit into a vehicle's storage. With this and a fully implemented strategy for updating the time zone (and country) information as needed in place, one can reverse-geocode the country/time zone based on the GNSS position obtained from the Location subsystem.
| Pros | Cons |
|---|---|
|
|
Phone connected through Bluetooth, Wi-Fi, or USB
Several technologies can be used to leverage a user's phone to obtain time and time zone data. For all phones, a pair of custom app and companion apps must be installed on the phone and on the In-Vehicle Infotainment (IVI) system. It's then possible to synchronize time at the desired interval. For example, upon establishing the connection and when the phone detects a new in time zone.
Some phones that support Bluetooth Low Energy (BLE) provide the option of retrieving time via the GATT Current Time characteristic and the Current Time Service Profile Specification 1.1. However, this option does not address a sufficiently large market segment to be exclusively relied upon.
| Pros | Cons |
|---|---|
|
|
Use sources
Every device vendor must determine how high a bar to set and which user journeys to deem most critical. Only with a clear understanding of the desired critical user experiences can the best decision be arrived at. In most cases, vendors must consider the tradeoffs between convenience and implementation complexity.
Each option described above poses advantages and disadvantages. For example, a critical design choice must be made with regard to how much resilience, as compared to occasional poor time display, is acceptable and how to manage the downsides. A fully automatic solution that can be expected to function well in all scenarios yet must be based on a combination of several information sources. No single option can provide 100% availability.
A manual configuration option as a temporary fallback is easy to execute and can, in practice, be sufficient for many users.