日曜日のスイスには、いつもより一時間多くありました。これは時計を合わせるときだけでなく、日別の訪問数を比べるときにも重要です。
2026年10月25日、スイスの時計は03:00から02:00に戻りました。現地の暦上の一日は、経過時間では25時間でした。同じ日付のUTCレポートは別の時間範囲を対象にします。どちらの定義も正しくても、合計は一致するとは限りません。
日別の増加を成長と呼ぶ前に、そのレポートで一日が何を意味するのか確認してください。
同じ日付でも時間範囲は異なる
2026-10-25という日付だけでは、期間は確定しません。タイムゾーンと境界が必要です。
Europe/Zurichの営業日なら、現地の午前0時から翌日の午前0時までと定めます。この二つの時点をUTCに変換してください。この区間では途中でUTCオフセットが変わるため、長さは24時間ではありません。
| レポートの定義 | UTCの開始、含む | UTCの終了、含まない | 経過時間 |
|---|---|---|---|
| Europe/Zurichの10月25日 | 2026-10-24 22:00 | 2026-10-25 23:00 | 25 |
| UTCの10月25日 | 2026-10-25 00:00 | 2026-10-26 00:00 | 24 |
仮に2026-10-24T22:30:00Zに発生したイベントは、チューリッヒでは10月25日、UTCでは10月24日に属します。イベントは変わっていません。レポートの境界が違うのです。
スイスの時刻変更はMETASの発表で確認できます。表はレポートの境界を計算した例であり、顧客の実測トラフィックではありません。
長さを求める前に境界を計算する
現地の暦日では、対象日の午前0時と翌日の午前0時を、同じ名前付きタイムゾーンで作成します。両方をUTCに変換してから差を取り、経過時間を求めます。終了を開始時点に86,400秒足した値で置き換えないでください。
このPythonの例は、zoneinfoとマシンにあるIANAのタイムゾーンデータを使います。Python 3.9以降とタイムゾーンデータが必要です。データがない場合は固定のUTCオフセットで代用せず、公式のtzdataパッケージを導入してください。この依存関係はPythonのドキュメントに説明されています。
from datetime import date, datetime, time, timedelta, timezone
from zoneinfo import ZoneInfo
zone = ZoneInfo("Europe/Zurich")
utc = timezone.utc
for day in (date(2026, 3, 29), date(2026, 10, 24), date(2026, 10, 25)):
start = datetime.combine(day, time.min, tzinfo=zone)
end = datetime.combine(day + timedelta(days=1), time.min, tzinfo=zone)
start_utc = start.astimezone(utc)
end_utc = end.astimezone(utc)
hours = (end_utc - start_utc).total_seconds() / 3600
print(f"{day}: {hours:g}h | {start_utc.isoformat()} to {end_utc.isoformat()}")
for fold in (0, 1):
local = datetime(2026, 10, 25, 2, 30, tzinfo=zone, fold=fold)
print(f"02:30 fold={fold}: {local.astimezone(utc).isoformat()}")
出力は次のとおりです。
2026-03-29: 23h | 2026-03-28T23:00:00+00:00 to 2026-03-29T22:00:00+00:00
2026-10-24: 24h | 2026-10-23T22:00:00+00:00 to 2026-10-24T22:00:00+00:00
2026-10-25: 25h | 2026-10-24T22:00:00+00:00 to 2026-10-25T23:00:00+00:00
02:30 fold=0: 2026-10-25T00:30:00+00:00
02:30 fold=1: 2026-10-25T01:30:00+00:00
意図的にUTCへ変換した後で引き算しています。Pythonのdatetimeの減算規則では、タイムゾーン情報付きの二つのオブジェクトが同じtzinfoオブジェクトを共有すると、現地の時計上の時刻を基準に計算します。それは、ここで求めたい経過時間とは異なります。
二つのfold値は、繰り返す一時間の中にある別々の02:30を指定します。現地時刻だけのラベルでは区別できません。イベントの実際の発生時点を保持し、繰り返す時刻の区別が必要な場面では、オフセットなどの曖昧でない識別情報を示してください。
これはローカルの計算です。計測リクエストの送信、アカウント設定の変更、製品のタイムゾーン切り替えの実演は行いません。
暦上の一日と直近24時間を分ける
チューリッヒの昨日と直近24時間は、別の問いに答えます。前者は名前付き地域の暦の境界に従い、後者はある時点で終わる一定の経過時間です。
当日のレポートも別のケースです。まだ一日分そろっていない場合があります。今日の10:00時点を昨日の終日と比較すれば、時計の変更がなくても観測時間が違います。
エクスポートや比較には、タイムゾーン、開始、終了、集計の規則を添えてください。表示ラベルだけでは不十分です。現地の時間単位を示すグラフなら、繰り返す一時間をどう表すか確認します。ラベルが24個あるから経過時間も24時間だとは限りません。
別の地域の営業日を分析するなら、その地域の境界を計算してください。チューリッヒのオフセットを他の市場へ流用したり、一時間の変更を普遍的な規則として固定したりしてはいけません。
件数が増えても、一時間当たりの率は変わらないことがある
仮のシステムが、経過時間一時間につき正確に10件のイベントを記録するとします。24時間では240件、25時間では250件です。合計は約4.17パーセント増えますが、一時間当たりの率は同じです。
これは算数であり、実際のトラフィックの予測ではありません。人の訪問は一定の率では発生せず、曜日、キャンペーン、対象者の構成も影響します。時間数で割ることはイベントの発生ペースを調べる助けになりますが、それだけで二日間が比較可能になるわけではありません。
すべての指標を時間で割るべきでもありません。ユニーク訪問者数は単純に足せるイベント件数とは異なります。コンバージョン率には、対象となる母集団と観察期間の明確な定義が必要であり、一日の長さでさらに割ればよいわけではありません。表示された率が単純に見えても、分母によって解釈が変わります。
判断に関係する場合は、合計と観測時間を一緒に示してください。仮の例と実測結果は明確に区別します。
境界も比較条件に含める
新しくクエリーを書く場合は、開始を含み、次の境界を含まない半開区間が便利です。つまりtimestamp >= start AND timestamp < endです。隣接する区間は境界を共有しつつ、ちょうどその時点のイベントを二重に数えずに済みます。
既存のレポートを黙ってこの規則に変更してはいけません。エクスポートを照合するときは、終了時点を実際に含むか、タイムスタンプの精度、フィルター、処理の完了状況、何を数えているかを確認します。日付の表記が同じでも、これらの規則が一致する証拠にはなりません。
実用的なテストには、通常の現地の一日、春と秋の切り替え、各境界ちょうどのイベント、繰り返す現地時刻の両方を含めます。期待するUTCの時点もテストの横に残してください。
すべてのダッシュボードを一つのタイムゾーンに統一することが目的ではありません。運用にはUTC、事業上の問いには現地の暦日が適切なことがあります。使う定義を明記し、同じ範囲を比較してから、差を成長と解釈してください。
