[58] 例えば政府が夏時刻の実施を1週間前に決定し、 プラットフォームの提供者が時間帯データベースの更新データを2日前に配信した場合、 プラットフォームがこれを取得し、 (プラットフォームおよび連続して稼働中のアプリケーションも含めて) 実施までに現に参照しているデータベースを新しい定義に置き換える必要があります。

[59] 例えば政府が夏時刻の実施の中止を直前に発表し、 プラットフォームの提供者の更新データ配布がそれに間に合わず実施翌日に配信した場合、 プラットフォームは誤って夏時刻に移行した後に更新データを適用することになります。 プラットフォームの地方時は夏時刻から標準時に戻すことになり、 時刻の不連続が発生します。 誤った夏時刻の実施中に夏時刻で記述された時刻は、 データベースの訂正後にも正しい時刻と解釈され続けるべきですが、 そのように実装されているかどうかはケースバイケースでしょう。

[3] 例えばシステム時計が夏時刻実施の影響を受けるとすると、 夏時刻の実施情報が適切なタイミングで配信されないと、 誤ったシステム時計の値に設定されることになりますから、 時刻に依存したあらゆるものの動作に悪影響が及びます。

[4] 例えばシステムが閏秒のないUTCで動作しているとき、 ログファイルの日時に TAI を使うとすると、 UTC と TAI の換算が必要となってきます。 換算に必要な閏秒の実施の情報が適切なタイミングで適用されていないと、 閏秒実施後のログファイル上の日時が不正確になってしまいます。 これではログファイルで後から動作状況を確認することが困難になるかもしれません。

[5] tzdata の時間帯の名前と定義は、たまに新しいものが追加されます。 アプリケーションのデータが更新されてもミドルウェアのデータが未更新の場合、 新しい時間帯を指定した時エラーになるかもしれません。

[14] 新元号への対応が各システムに行き渡る前に新元号を使ったデータを送信すると、 古いままのシステムが処理できないおそれがあります。