GPXを別アプリへ移す前は、地図の線だけでなく、点ごとの時刻が入っている場所と日時の末尾を確かめます。時刻の数字が9時間違って見えても、すぐに書き直す必要があるとは限りません。2026年10月29日時点のGPX 1.1、XML Schema、時刻とサービスの公式資料をもとに、移行前に残す確認メモを整理します。原本を保管し、変更の要否を判断してから複製で進めるのが基本です。
点の時刻とファイル全体の日付を分ける
GPX 1.1の仕様では、ファイルの説明情報を置くmetadataの中にも、点の情報を置く場所にもtimeがあります。トラックの点はtrkptで表され、共通の点の型wptTypeを使います。その型ではtimeはxsd:dateTimeという日時の型で、出現は任意です。したがって、ファイルの先頭付近に日付が一つ見つかっただけで、歩いた点すべての時刻がそろっているとは判断できません。
見る対象は、移したいトラックの各点にあるtimeです。点の中にある時刻と、metadataにある時刻を別々に控えます。routeの点rteptも同じ点の型を使うため、rteという要素名だけで「日時は入らない」と決めつけないことも大切です。一つの項目が任意であることは、ファイル全体の形式や内容が正しいという証明にはなりません。
編集部の提案として、最初に移すトラックを選び、その中の先頭・途中・末尾の点を見て、時刻がある場所をつかみます。これは部分的な下見です。全点にあると確認するには、選んだ範囲の全点を調べる必要があります。timeという文字の検索件数だけを数えると、別の場所の日時を一緒に数えるため、点の数との単純比較で完了にしません。
Z・時差付き・末尾なしを区別する
日時は、年月日と時分秒に加えて末尾まで読みます。W3CのXML SchemaのdateTimeでは、文字としての日時表現に、Zや+09:00のような時間帯の指定を付けられます。この型の文字列表現では時間帯を省く形も定義されています。ZはUTCを表す表記で、+09:00はUTCから9時間進めた時間帯の指定です。末尾の違いを見ずに、時計の数字だけを比べないことが要点です。
同じ仕様には、時間帯付きの値を正規化した表現ではZを使う、という規定もあります。これは、時差付きの文字列表現があることと矛盾しません。書かれた文字と、それが表す時点を分けて考えます。ただし、型が表現できることと、移行先がそのファイルを受け入れることは別です。個々のアプリの受入条件まで、この型の説明だけで決められるわけではありません。
たとえば末尾のない2026-10-29T06:00:00を見つけたら、その文字列だけから日本時間の朝6時と決めません。編集部の点検案では、元アプリで表示した時間帯、書き出し機能の説明、記録時のメモを一緒に確かめます。分からない時刻に、とりあえずZを付けて再取り込みする手順にはしません。
9時間の見かけの差を一括修正しない
NICTは、日本標準時をUTC(NICT)から9時間進めた時刻と説明しています。この関係を使った架空の読み取り例では、2026-10-29T06:00:00+09:00と2026-10-28T21:00:00Zは同じ時点を表します。日付と時計の数字が違っていても、末尾を含めて換算すれば一致します。実際の登山や機器の記録を示した例ではありません。
一方、2026-10-29T06:00:00Zと2026-10-29T06:00:00+09:00は、同じ時点ではありません。数字を残して末尾だけ置き換える操作は、同じ時点を別の時間帯で書き直すことと異なります。「9時間違うから全点に9時間を足す」と決める前に、元の末尾と表示側の時間帯を確認します。
比較は同じ対象で行います。先頭の点を見ているのか、アプリが示す活動の開始表示を見ているのかをメモし、対応する値を探します。途中や末尾にも食い違いがあるなら、その位置を残して確認します。ずれの量だけから端末時計の故障、受信の途切れ、編集による結合などの原因を断定せず、原因不明のまま全体を書き換えない方針です。
移行先の条件を調べ、一本で照合する
Stravaのヘルプは、各座標に時刻がないGPSファイルではセグメントの速度や時間を計算できず、アップロードを拒否すると説明しています。開発者向けのアップロード資料でも、GPX 1.1に従うことと、各トラック点の時刻を求める条件が示されています。GPXの点のtimeが任意であることと、このサービスの活動取り込みに時刻が要ることを分けて確認します。他のアプリも同じ条件だと広げません。
時刻付きファイルが必要な場合、同ヘルプは、元の活動の所有者に本人のGPXを書き出して送ってもらう方法を案内しています。時刻付きのGPSファイルを入手できなければ、手動の活動を作成する選択肢も示します。これは実際の時刻が戻るという意味ではありません。取り込みを通す目的で仮の時刻を入れ、実測の記録として扱う手順は勧めません。
編集部の運用案は、原本を残した一本の複製で結果を照合することです。移行前に対象トラック、日時を見た点、元の文字列と表示の時間帯を控えます。移行後は同じ対象について、開始・終了の表示やエラー内容を記録します。使う画面に時間帯の説明がなければ公式ヘルプで確認し、理由が分かるまでは大量のファイルをまとめて修正しません。
まとめ：日時の場所・末尾・結果を残す
日時点検は、時刻がどの点にあるか、末尾が何を表すか、移行先が何を要求するかの順に進めます。最後に残すのは、対象範囲、確認した日時、時間帯、照合結果のメモです。記録の内容を変える必要があるのか、表示の読み方をそろえればよいのかを分けてから判断します。解釈できない点を空欄のまま残し、原本を保持して確認を続けることも、移行作業の一つの結論です。