時刻を正確に表示することは、自動車のインフォテインメント システムに求められる主要な機能です。これは一見単純に見えるかもしれません（特に、時刻やタイムゾーン管理に関して満たすべき要件が厳密ではない場合）。ですが、手動の操作なしで正確な日付と時刻を確実に表示する必要性がある場合には、時刻は複雑な課題になります。
システム オン チップ（SoC）で通常使用されるすべてのリアルタイム クロックでは僅かなずれが発生します。このずれは時間の経過とともに蓄積するため、修正しないままにしておくと重大なエラーが発生する可能性があります。また、ユーザーは現地時間が正確に表示されることを期待します。そのため、協定世界時（UTC）からのオフセットを適切に行う必要があります。
タイムゾーンに関する情報、および夏時間（DST）の適用に関する情報は、自動車の耐用年数が経過するまでに変更される可能性があります。たとえば、ブラジルでは何年もの間 DST を採用していましたが、2019 年に DST を廃止することを決めました。
Android には、タイムゾーン ルール管理の複雑さを解決するために必要なインフラストラクチャが用意されています。詳細については、タイムゾーン ルールをご覧ください。これにより、OEM はシステム アップデートを行わずに、更新されたタイムゾーン ルールのデータをデバイスにプッシュできます。このメカニズムにより、以下が可能になります。
- ユーザーがタイムリーなアップデートを受け取れるようになる（Android デバイスの耐用寿命が延びます）。
- OEM がシステム イメージのアップデートとは関係なくタイムゾーンのアップデートをテストできる。
注: AAOS 10 は、Android 10 以降のリリースで提供される APEX ベースのモジュール アップデート メカニズムをサポートしていません。
注: このメカニズムを実装するには、システムの再起動が必要です。
自動車における時間（タイムゾーン）情報のソース
Android デバイスではシステムレベルで UNIX 時間で時間を管理しており、目的のタイムゾーンの修正を適用してから、値を現地時間に変換してユーザーに表示しています。現在のユーザーのゾーン ID（Olson ID とも呼ばれます）は、設定として保存されます。たとえば、Europe/London などがあります。
以下に概説するメカニズムのほとんどは、時間情報に関するものです。これらの規格の目的は、適用されるタイムゾーン ルールについて記述することではなく、現在時刻をユーザーに提示することです。実際のタイムゾーンを特定するには、国、オフセット、DST オフセットなどの要素から逆算して、ゾーン ID を設定する必要があります。
このプロセスは、場合によっては困難になる場合があります。利用可能な情報に基づいて行う逆算があいまいになる可能性もあり、たとえば、タイムゾーン ルール America/Denver では DST が適用され、夏期には山岳部夏時間（MDT）になります。一方、America/Phoenix では常に山岳部標準時（MST）を適用します。
セルラー方式
システム情報（SI）は、Long-Term Evolution（LTE）無線インターフェースに不可欠な要素であり、基地局（BS）により報知制御チャネル（BCCH）を介して送信されます。3GPP TS 36.331 は、GPS、協定世界時（UTC）、現地時間オフセット、DST に関する情報を含む SystemInformationBlockType16（SIB16）を指定します。
2G や 3G にも似たような機能があり、ネットワーク ID やタイムゾーン（NITZ）に関する情報がブロードキャストされる場合があります（詳しくは、3GPP TS 22.042 をご覧ください）。また、他のセルラー通信規格にも同等の機能があります。
残念ながら、このような情報がすべての通信規格で必ずブロードキャストされるわけではありません。つまり、すべてのネットワークで普遍的に情報が利用できるわけではありません。
| 長所 | 短所 |
|---|---|
|
|
ネットワーク タイム プロトコル
ネットワーク タイム プロトコル（NTP）は、比較的正確な UNIX エポック時刻に関する情報を取得するためによく使用されます。Android では NewNetworkTimeUpdateService を使用して、システム時刻を NTP サーバーのシステム時刻と同期できます（これはすぐに利用できます）。NTP はネットワーク時刻をモニタリングします。同期がとれなくなり、なおかつ携帯通信会社が直近で NITZ を更新していない場合、NTP がシステム時刻を更新します。ユーザーが NITZ を利用できない場合に AUTO_TIME を有効にすると、システムはネットワーク時刻をすぐにチェックします。
| 長所 | 短所 |
|---|---|
|
シンプルで、Android でサポートされています。 |
|
ブロードキャスト ラジオ チューナー
内蔵のチューナーを活用して、時刻とタイムゾーンに関する情報を取得する機能は魅力的ですが、それには課題がいくつかあります。数多くの無線放送規格は、目的の情報を公開するためのオプションを定義しています。一般的には、ブロードキャスト ラジオ チューナーはセルラー方式と同じ情報を提供します。
ETSI EN 300 401 V1.4.1（2006-06）のセクション 8.1 では、オーディオ プログラムと Digital Audio Broadcasting（DAB）システムのデータの両方のサービスに関する補足情報を提供するサービス情報機能を規定しています。セクション 8.1.3 では、時刻と日付の形式、および国と現地時間のオフセットに関する情報を定義しています。
同様に、FM チューナーに一般に実装されている Radio Data System（RDS）に関しては、EN 50067 標準のセクション 3.1.5.6 で、1 分ごとに送信される時刻とデータの形式を定義しています。また、送信されるプログラム ID の一部として、拡張国コード（ECC）を取得することもできます。
HD Radio には、Station Information Service（SIS）Parameter Message（MSG ID 0111）の HD Radio™ Air Interface Design Description Station Information Service Transport 仕様の一部として、対応するオプションが含まれています。セクション 5 では、放送のクロック サポートを使用する際に注意しなければならない注意事項が明確に説明されています。この注意事項は、他のシステムにも等しく当てはまります。
| ...これらのデータは、放送局がある場所の現地の慣習を説明しています。これは、受信者がいる場所の現地の慣習と同じである場合とそうでない場合があります。タイムゾーンの境界の近くにおいては、受信者は複数の放送局が送信する異なるデータを同時に受信する可能性があります。そのため、これらのデータはヒントとしてのみ提供されます。その解釈と利用は、データの利用者の管理下で裁量に基づき行う必要があります。…" |
また、少なくとも HD Radio 場合、この情報のブロードキャストは任意であるため、排他的に依存するべきではありません。
| 長所 | 短所 |
|---|---|
|
|
実装のヒント
現在の BroadcastRadio Hal 2.0 は、時刻およびタイムゾーンに関するメタデータを処理するためのプロビジョニングを提供していません。そのため、推奨されるソリューションは、ベンダー拡張機能を活用することです。この機能の実装は、Hardware Abstraction Layer（HAL）で行う必要があります。その後、汎用の RadioTuner.getParameters() メソッドを使用して RadioManager のクライアントに公開できます。
ソリューションの堅牢性を維持するために、このベンダー拡張機能の利用者は、HAL がその機能をサポートしていることを確認する必要があります（必ずしもサポートしているわけではありません）。getParameters 呼び出しのパラメータ文字列は、ベンダーが明確に使用できるように整理する必要があります。たとえば、組織の名前空間を使用する場合、"com.me.timezoneTuner.currenttimezone" のように適切なドメインを接頭辞として追加します。
情報のイベント ドリブンの性質を考えると、この情報の受信には RadioTuner.Callback.onParametersUpdated() コールバックを使用することをおすすめします。この機能を構成可能にする必要がある場合は、setParameters 上に一連のカスタム ルーティンを設計します。次に例を示します。
com.me.timezoneTuner.currenttimezoneEvent.enable
全地球航法衛星システム
全地球航法衛星システム（GNSS）自体は、（非常に）正確な時間情報と位置情報しか提供しません。
位置情報
この問題に対する解決策は、リバース ジオコーディングを実施し、位置に基づく検索を行って国とタイムゾーンを決定することです。自動車の位置情報を取得するうえで GNSS は明らかに最適な手段であり、最高品質の情報を提供します。Google の<aclass="external" l10n-attrs-original-order="href,class" l10n-encrypted-href="6z2vbshndiNBlkSF5nuHzqXc57TIW5VywCkhSp4WUypzRwGNXACB5ltAIGicGTa2qjmYZJAor4qTntaXrxsSZqMZz/kq5DDJnT+TJu5E3bE=">タイムゾーン API は、必要な変換を行うために必要なすべてのものを提供します。それには、もちろんインターネット接続が必要です。オンライン ソリューションを実装する際には、ユーザーのプライバシーを最優先事項としてください。データ使用の費用を受け入れるかどうかについてユーザーから許可を受ける必要があり、許可をリクエストする必要があります。</aclass="external">
また、オフラインでの使用に適したソリューションを構築することもできます。国とタイムゾーンを正確に決定するための十分な解像度を持つローカル マップ データベースは、自動車に搭載されたストレージに格納できます。これに加え、必要に応じてタイムゾーン（および国）情報を更新するための方法を完全に実装することで、ロケーション サブシステムから取得された GNSS の位置に基づいて国 / タイムゾーンをリバース ジオコーディングすることができます。
| 長所 | 短所 |
|---|---|
|
|
Bluetooth、Wi-Fi、USB で接続されたスマートフォン
いくつかのテクノロジーを利用して、ユーザーのスマートフォンから時刻とタイムゾーンに関するデータを取得できます。使用するスマートフォンが何であれ、カスタム アプリケーションとコンパニオン アプリのペアをそのスマートフォンと車載インフォテインメント（IVI）システムにインストールする必要があります。その後は、任意の間隔で時刻を同期できます。たとえば、スマートフォンとの接続が確立された状態で、スマートフォンが新しいタイムゾーンを検出したタイミングで同期させることができます。
Bluetooth Low Energy（BLE）をサポートしている一部のスマートフォンでは、GATT Current Time 特性と Current Time Service Profile Specification 1.1 を介して時刻を取得するオプションが提供されます。ただし、このオプションは十分な規模の市場セグメントに対応していないため、排他的に依存するべきではありません。
| 長所 | 短所 |
|---|---|
|
|
ソースの使用
すべてのデバイス ベンダーは、基準をどの程度にするか、および、どのユーザー操作を最重要視するかを決定する必要があります。重要視するユーザー エクスペリエンスを明確化することで、最適な意思決定を行えるようになります。ほとんどの場合、ベンダーは利便性と実装の複雑さの間のトレードオフを考慮する必要があります。
ここまでで説明したオプションには、それぞれ長所と短所があります。たとえば、時刻表示がときおり不正確になることをどの程度許容できるか、および短所をどのように管理するかに関して、重要な設計上の選択を行う必要があります。すべてのシナリオで適切に機能することが期待できる完全に自動化されたソリューションを構築するには、いくつかの情報ソースを組み合わせる必要があります。100% の可用性を実現できる単一の選択肢はありません。
一時的なフォールバックとしての手動構成オプションは実行が簡単であり、実際には多くのユーザーにとって十分なものになります。