どちらの方法でも、何が変化しているかに応じて、さまざまな方法で失敗します。
-
タイムスタンプを対応するタイムゾーンに
2013-12-29 12:34:56 America/New_Yorkとして保存する場合 、たとえば、ブロンクスが突然独自のタイムゾーンAmerica/New_York_Bronxを開始した場合、これは失敗します。 別のオフセットで、あなたのイベントはたまたまブロンクスにありました。これがどの程度発生する可能性があり、障害がどの程度悪化するかを判断します。
-
タイムスタンプをUTCで保存し、イベントが発生しているタイムゾーンがオフセットを再定義している場合（たとえば、DSTの日付をシフトしたり、完全に別のオフセットにシフトしたりする場合）、イベント時間はその場所の実際の壁掛け時計の時間と異なる場合があります。
2013-12-29 12:34:56 UTCを保存する場合 ドイツのベルリンで13:34:56に開催されたイベントの場合、ベルリンはDSTを変更します。2013-12-29 12:34:56 UTCイベントは実際には現地時間の13:34に発生していますが、現在はベルリンの現地時間の14:34:56に対応している可能性があります。これがどの程度発生する可能性があり、障害がどの程度悪化するかを判断します。
-
UTCタイムスタンプを保存し、それを物理的な場所にリンクしてからタイムゾーンにリンクすると、両方の問題に対処できます。ただし、このためには、「ニューヨーク」だけでなく、正確な物理的な場所を保存する必要があります。そうでない場合は、ケース1があり、もう1つの中間ステップがあります。正確な物理的な場所を保存し、この場所をタイムゾーンに解決する正確な方法があり、タイムゾーンデータベースを最新の状態に保つと、ほとんどすべての変更シナリオを処理できます。
これがどれほど実用的であり、この余分な精度があなたにとってどれだけの価値があるかを決定します。