フランスの現場で使う障害ログ、時刻を現地語表記にしたら読めなくなった話

フランスの小規模チーム（開発5人、運用は兼務）で、障害対応のログをSlackに流す小さなツールを保守している。構成はNode 20、cronで5分おきにAPIを叩き、失敗したらチャンネルに投稿するだけのもの。データ量は1日200〜400行程度で、多い日でも1,000行には届かない。問題は時刻の表示だった。当初はISO 8601のUTCをそのまま出していたが、「今どのくらい前の障害か」を現地の運用担当が毎回換算していて、初動が遅れていた。

やったことは2つ。保存はUTCのまま、表示だけEurope/Parisに寄せた。NodeならIntlで足りる。

const fmt = new Intl.DateTimeFormat('fr-FR', {
  timeZone: 'Europe/Paris',
  dateStyle: 'short',
  timeStyle: 'medium',
});
// 2024-03-31T00:30:00Z -> 31/03/2024 02:30:00

ただし夏時間の切り替え日は1日が23時間か25時間になる。差分を「何分前」で出す箇所は、表示文字列ではなくエポックミリ秒の差から計算するように変えた。ログ本文にはUTCも併記し、表示だけ現地時刻にした。

const diffMin = Math.round((Date.now() - Date.parse(ts)) / 60000);
const line = `${fmt.format(new Date(ts))} (UTC ${ts}) / ${diffMin}分前`;

なぜ保存をUTCのままにしたか。過去ログを grep するとき、夏時間で同じ時刻が2回現れると一意に特定できなくなる。表示の都合で保存形式を変えると、後から検索する側が壊れる。代わりに表示のたびに変換するコストを払う。1日数百行なら無視できる。

失效するのは、外部サービスのログをそのまま貼る場合だ。向こうが現地時刻で出していると、UTC併記の前提が崩れる。実際に、あるAPIのレスポンスがタイムゾーンなしの文字列で、パリ時間と誤解して1時間ずらして読んだことがある。あとは fr-FR の日付順（日/月/年）に慣れていないメンバーが「03/04」を3月4日と読む事故も起きた。月名を出すか、ISOを並記するのが安全だった。

みなさんのところでは、外部から来る時刻文字列のタイムゾーンをどこで確定させていますか。