電話での時間：何がどのように機能するか

確かに多くの人が内蔵時計の読みに問題があることに気づきました。 誰かがSMSに関連する時間の表示に奇妙なことに気付いているかもしれません。 これは、多くの国で冬時間または夏時間への移行がある日の後、すぐに特に顕著です。



これがどのように機能するかを理解するには、アーキテクチャを少し掘り下げる必要があります。 そのような問題が発生し、それが時間に影響を及ぼし、電話が突然間違った時間を表示し始めた場合に何ができるかを理解してみましょう。

標準時

2011年の連邦法No. 107-FZで「時間の計算について」と呼ばれているように、地理的および管理上の「タイムゾーン」または「タイムゾーン」については、Wikiに記載されているため、説明しません。



この基本情報から、標準時と「ユニバーサル」（UTC）（「グリニッジ」に相当する日常生活-GMT）の差は、当局の純粋な管理行動の結果であることを覚えておくことが重要です。 電力の特定の地域にどのような違いが割り当てられるか、そうなります。 まず、ネットワーク機器の時間処理の機能を理解してみましょう。

時間とSMS

電話から送信されたテキストメッセージ（SMS-SUBMIT）には、時間情報の場所がまったくありません。



メッセージがSMSセンターに到着した時点でのみ、タイムスタンプフィールド-TP-Service-Center-Time-Stamp（TP-SCTS）を取得します。これは、7つのオクテットと再配置されたハーフオクテット（GSM 03.40、TS 23.040）で構成され、情報をバイナリで表します10進コード（BCD）、つまり、各半オクテットが1桁をエンコードします。



最初の6オクテットは、送信者の現地時間の年、月、日、時間、分、および秒を表します。

7番目のオクテットにはタイムゾーンに関する情報が含まれ、現地時間とUTC（GMT）の差を示します。 時間差の単位は15分間隔で、3番目のビット（右半分のオクテットの最上位）は、差の代数符号を示します（「0」は正、「1」は負）。

タイムゾーン情報の値では、「夏時間」を考慮する必要があります。 たとえば、英国では、タイムゾーンのオクテット値は冬時間では00000000b（UTC + 00：00）、夏時間では01000000b（4 x 15分、つまりUTC + 01：00）です。



受信者の電話に配信されるショートメッセージ（SMS-DELIVER）の構造では、SMSセンターへのメッセージの到着時間に関する情報が既に存在し、ユーザーがメッセージに関する情報を表示するときに電話で使用できます。

モバイルネットワークが電話に伝えることができる現在時刻に関する情報

1996年、GSM仕様（GSM 02.42、04.08など）で、携帯電話会社が日付、時刻、タイムゾーンに関する情報を携帯電話に配信できるツールが登場しました。 このため、モビリティ管理を目的としたシグナリングメッセージには、オプションであるため、オペレータの裁量で使用できる情報要素がいくつかあります。



まず、 IEの「タイムゾーンと時間」情報要素です。 ネットワークがアラームメッセージを送信する瞬間を示すデータの複合体全体（年、月、日、時、分、秒）と、ベースステーションが位置するタイムゾーンを示す値が含まれています。

年、月、日、時、分、秒の値は、SMSの場合のように、半オクテットの再配置でBCDエンコードで送信されますが、SMSセンターのタイムスタンプとは異なり、ローカル時間ではなく世界時（UTC）を示します！



タイムゾーンを示す情報要素の部分は、SMSセンターのタイムスタンプの場合と同じエンコードで送信されます。



特定の時点で電話に転送される情報のブロックは次のとおりです。



オクテットの意味/解釈

47 , , 7 IE «Time Zone and Time»

11 YEAR: 11

20 MONTH: 02

71 DAY: 17

70 HOUR: 07

71 MINUTE: 17

30 SECOND: 03

21 TIME ZONE: 12 = GMT+03:00

49 , , IE «Daylight Saving Time»

01 IE «Daylight Saving Time» = 1

00 , - « »







この情報要素では、ネットワークは「世界時」の値-UTCを送信するため、電話が現地時間を表示するには、電話が位置するタイムゾーンのタイムオフセットに対応する値でUTCを調整する必要があります。 この特定のケースでは、「時間の計算について」という法律が採択され、冬時間への移行が取り消される前でさえ、モスクワで発生しました。



したがって、ネットワークによって送信される時間は、2011年2月17日のモスクワ時間の午前10時17分3秒に相当します。 比較のため、最近電話に転送された情報ブロック：



オクテットの意味/解釈

47 , , 7 IE «Time Zone and Time»

21 YEAR: 12

40 MONTH: 04

81 DAY: 18

80 HOUR: 08

45 MINUTE: 54

44 SECOND: 44

61 TIME ZONE: 16 = GMT+04:00

49 , , IE «Daylight Saving Time»

01 IE «Daylight Saving Time» = 1

00 , - « »

12:54:44 18 2012 .







タイムゾーンと時間情報要素に加えて、仕様では、タイムゾーンに関する情報のみを送信するように設計された個別の8ビット情報要素も提供しています（ タイムゾーンIE ）。



その中の情報は、SMSセンターのマークのタイムゾーンの値と同じ方法でエンコードされます。

ただし、「タイムゾーンと時間」とともに「タイムゾーン」を送信することはほとんど意味がありません。



また、別の情報要素（ 「サマータイム」IE ）があります。これは、送信された場合、「サマータイム」の使用に起因するタイムシフトの値を示し、タイムゾーンフィールドの値を計算するときに考慮されます。



特定の値は、シフトがないこと（「00b」）、+ 1時間のシフト（「01b」）、さらに+2時間のシフト（「10b」）を示す場合があります。



GSM / 3GPP仕様によると、電話がネットワークに登録されたとき、タイムゾーンが変更されたとき、または夏時間または冬時間に切り替わったときに、できるだけ早く時間情報を携帯電話に配信する必要があります。



したがって、上記の手段を使用して、ネットワークは、現在の時刻、および短いメッセージに関連する時刻の正しいインストールと表示に必要なすべての情報を電話に提供できます。



しかし、標準の規定によると、この情報の使用は、電話メーカーの裁量のみを目的としています。



ただし、ユーザーは、電話およびその製造業者とは完全にまたは部分的に独立した理由でいくつかの問題を経験する場合があります。



たとえば、複数のタイムゾーンにサービスを提供するSMSセンターでは、送信元の電話の場所の時間を考慮する必要があります。 それ以外の場合、SMSを送信する時間は、SMSセンターと送信元の電話が配置されているタイムゾーンの時間差に等しいエラーで修正されます。 時間帯の境界近くに位置するエリアでは、オペレーターは、基地局がその地域に位置する時間帯の値を基地局が送信することを確認する必要があります。 もちろん、事業者はネットワークを計画および設定するときにこれらの機能を考慮します。



ただし、電波の伝搬の法則により、オペレーターは電話に配信される時間情報の正確性を完全に保証することはできません。 結局のところ、タイムゾーンの管理境界の近くにある電話は、近隣のタイムゾーンにある基地局から信号を受信し、日付と時刻に関する情報を使用して、関連情報を送信できます。



同じ理由で、SMSが隣接するタイムゾーンにある基地局を介して送信された場合、SMSセンターは電話が実際にあるタイムゾーンを誤って決定する可能性があります。



さらに、ネットワーク機器とSMSセンターのソフトウェアが新しいロシアの現実に反して自動的に夏/冬時間に切り替わる、または試運転時に誤って設定されたという事実により、短期的な問題が発生する可能性があります。 しかし、このような「ニュアンス」は通常、保守担当者によって迅速に修正されます。

時間と場所に関するその他の情報源

携帯電話の滞在日、時間、場所に関する情報を提供する他のチャネルがあります。



多くの電話にはナビゲーター機能があり、測位システム（GPS、GLONASSなど）からの時間と位置の情報を使用できます。



インターネットに接続された電話（タブレット）は、NTPまたはSNTPを使用した追加の時間情報、およびパブリックIPアドレスの「バインド」の場所に関する情報を使用できます。

時間と時間帯の手動設定に加えて、場合によってはこのような豊富な初期情報は、選択する電話に問題を引き起こす可能性があります-時間と場所に関するどの情報を使用するか。

電話での時間情報の使用方法

携帯電話では、時計はかなり単純な構成で最初に登場しました-単にディスプレイに時刻を表示しました。 移動したり、夏や冬に時間を変えたりする場合、新しい現実に合わせて時計を設定するだけで十分でした。



当然、電話機の日付と時刻のパラメータを手動で設定する機能は引き続き保持されます。



手動設定では、ユーザー自身が現在の日付、時刻、および場所（タイムゾーン）を入力し、入力した情報の正確性について責任を負います。



すべてがシンプルで曖昧でないように思えますか？

ただし、手動設定オプションでは、タイムゾーンとユーザーが自分の場所として指定した都市との間の対応が電話のソフトウェアにある場合、問題が発生する可能性があります。



タイムゾーンに間違った値を使用した場合、その後、別の都市/国に移動し、対応するタイムゾーンの値が変更されると、電話の時間が新しい場所の実際の管理時間と異なることがわかります。



プロセッサのパフォーマンスとメモリ要素の容量が増加するにつれて、電話は時間、日付、カレンダーに関連するより複雑な機能を統合し始めました。



そして今、日付と時刻を設定するための自動モードの状況は、はるかに興味深いように見えます。

電話が登録されているGSM / UMTSモバイル通信ネットワークが現在の日時に関する情報を送信しない場合、自動モードが設定されているにもかかわらず、電話はユーザーが手動モードで入力したデータを表示するように見えるはずです。 ただし、一部のモデルの開発者が測位システムまたはインターネットからの情報を使用できることを完全に排除することはできません。



信号トラフィックのオペレーターが日付、時間、およびタイムゾーンに関する情報を送信する場合、最も論理的な方法は、この情報を使用することです。UTC値に基づいて計算された現地時間と、オペレーターから受信したタイムゾーンシフトを表示することです。



ただし、実際には、一部のメーカー（ソフトウェア開発者）は、他の情報源を引き付ける際に常に合理的なイニシアチブをとるわけではありません。 たとえば、自動時刻修正モードでは、一部のモデルは、何らかの理由で、ネットワークから送信されたタイムゾーン情報を使用する代わりに、手動設定モードでユーザーが設定した値を使用します。



2011年の連邦法第107-「時間の計算について」に基づくロシア連邦のタイムゾーンの変更に関連して、ソフトウェアが以前に開発された携帯電話では、多くのロシアの都市のタイムゾーンのデータが不正確になりました。 その結果、そのような電話機がネットワークから受信したタイムゾーンに関する情報の代わりに手動設定で設定された値を使用する場合、時刻が正しく表示されない場合があります。



明らかに、このようなエラーの修正は、オペレーターから受け取った情報を使用する責任を負うハンドセットメーカーによって処理される必要があります。

しかし、激しい競争に直面して、ますます多くの新しいモデルのリリースを確実にしようとするメーカーは、以前にリリースされたモデルのソフトウェアの変更をすぐにやめます。



このような場合、上記の連邦法に従って調整されたタイムゾーン値を手動で設定すると役立ちます。



たとえば、モスクワの場合、都市の名前（バクー、エレバン、トビリシなど）に注意を払うことなく、UTC + 03：00ではなく、UTC + 04：00の古い値を設定できます。



一部の古い電話機は、ネットワークから受信した時間値を世界時ではなくローカル時間として扱うため、時刻が正しく表示されない場合があります。 明らかに、この場合も、ソフトウェアの新しいバージョンを開発して問題を解決できるのは製造業者だけです。 真実であり、希望することは困難です。



SMSを送信する時間の解釈に関するいくつかの問題も知られています。 受信側の電話は、SMSで、送信側の電話が片側に位置していた現地時間とタイムゾーンに関する情報、およびネットワークから、SMS受信場所のUTCとタイムゾーンの値を受信します。



さらに、受信者の電話は、メーカーが意図するすべての情報をこの情報で処理できます。所有者に表示する前にこの情報をすべて処理する方法は、電話メーカーの責任にのみ基づいています。



残念ながら、一部のモデルのソフトウェア開発者は、SMS送信時間のパラメーターを処理するときにミスを犯し、ユーザーを誤解させました。



時間表示で起こりうるすべての問題を網羅的に説明することを主張せずに、特定のケースで問題の原因を理解し、許容できる解決策を見つけることができるメカニズムを説明しようとしました。