回答:
正直なところ、これはWebサイトが複数のタイムゾーンで使用されているときによく見られる問題の1つです。戦いを克服する方法の長いリストがあります。badpを要約すると、さまざまなタイムゾーンがどのように処理されるかについては、多くの要因があります。
ほとんどのWebサイトでは、この問題に対処するために2つの異なるソリューションのいずれかを選択しています。
1）日付に関係するものはすべてデータベースにUTCとして保存します...そして、ユーザー定義の設定をWebサイトのユーザーが使用しているタイムゾーンを選択できるようにします...またはgeo-ip-lookupマジックを実行して調べます世界のどこにいて、適切なタイムゾーンを見つけます...そして、日付を表示するたびに...ローカライズに必要な関数を必ず呼び出してください。ほぼすべてのプログラミング言語には、指定されたタイムゾーンを使用して日付を表示する方法がいくつかあります。また、ユーザーが日付を挿入する場合は、これを逆に行う必要があります。（現地時間を取り、DBストレージ用にUTCに戻す）これはおそらく最も一般的なアプローチです。これにより、「ホイールの再発明」にかける時間を大幅に節約できます。匿名の訪問者が行く限り... A）EST / EDTに固執するか（組み込みの関数呼び出しを使用して、必要に応じて表示する）、またはB）Geo-IP-Lookupに戻り、経験に基づいた推測に基づいてタイムゾーンを選択します。また、日付/時刻を表示しているタイムゾーンを常に指定することもお勧めします。つまり、「12:00」と決して言わないでください...「12:00 EDT」と書かれていることを確認してください
または2）現在と投稿が作成されたときの違いを表示するstackexchangeのモデル（および他の多くのモデル）に従います。つまり、「x日に投稿」の代わりに...「x時間前」または「x日x時間前」などを実行します...または、将来の日付については「6日14時間...」多くの状況で急速に一般的になりつつありますが、カレンダータイプのスケジュールには理想的ではありません。
もちろん、この2つのハイブリッドを採用することもできます。さらに一歩進んで日付をutcとして保存する必要があるかもしれませんが、イベントの特定のタイムゾーンも保存する必要があります。最終的に、決定はあなた次第です。
ここに問題があります：EUと米国は同時にDSTをオン/オフにしません。この3月には、これらのイベント間に3週間の違いがありました。
この期間に発生することは次のとおりです。たとえば、毎日同じ時間にイベントがあり、米国を拠点としているため、米国の夏時間を使用して時刻を調整するとします。
Day (2001) United States Europe United Kingdom Global Time delta
March 5th EST 1500 CET 2100 GMT 2000 GMT 2000 +23h
March 6th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
March 7th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
..............................................................................
March 26th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
March 27th EDT 1500 CEST 2100 BST 2000 GMT 1900 +24h
すべての可能性を分析しましょう：
グローバルタイムゾーンで時刻を表示し、それをUTCと呼びます。これは適切なことのように思われますが、米国の顧客が混乱し、異なるUTC時刻（昨日午後8時、今日午後7時）が表示されます。同じウォールクロック時間（昨日午後3時、今日も午後3時）、そしてポストされたタイムクロックが変更されていないにもかかわらずウォールクロックイベント時間を変更する必要があるEUベースの顧客。
グローバルタイムゾーンで時刻を表示してGMTと呼ぶと、米国の顧客を混乱させるだけでなく、GMTからBSTに切り替える英国の顧客も混乱させることになります。EDT 1500とEST 1400は同じ瞬間であることを理解するのは直観に反しています。これをBST / GMTに変換します（サイトのどの部分でもBST時間を表示しないという追加の問題があります）。
EUタイムゾーンでタイムゾーンを表示する場合（私はGMT / UTCの混乱を避けるためにCET / CESTを使用しました）、それは明らかに、米国の顧客にとって非常に混乱するでしょう。時計の時間自体が変わります。米国の顧客は最初の切り替えの準備をしているかもしれませんが（結局、同じ日に壁時計を変更する必要があります）、後者に驚かれることでしょう。
米国のタイムゾーン（EST / EDTなど）でタイムゾーンを表示すると、上記とまったく同じ状況になりますが、ミラーリングされます！
これは絶望的な状況のようです！これが私が4年（この例では1年に2回）の苦境を乗り越えた後、「タイムゾーンを構成する」という方法で対処する方法です。
私はまさに上記の状況にあるので、「1500 NYT」を記述して、「ニューヨークが使用しているタイムゾーンでの午後3時」を意味するように「NYT」（ニューヨークタイムゾーン）を作成しました。
これには、DSTウォルツァーが発生していることをユーザーが知っている限り、ユーザーが自分のタイムゾーンに相互に変換する非常に単純な方法があります。それは、ニューヨークの時間を確認するためのgoogle " time in new york "です。 、そこから解決します。空想を得て、time.is/15:00_in_New_Yorkなどの地理位置情報ベースのサービスを使用することもできます。
注あなたは、ことながらでき time.isに時間帯省略形の名前を使用して、彼らはかなりそれをすべてについて自分自身を混同しているため、私は、あなたを促すない：ESTは、EDTと同じ時間を持ってい ‽
DSTについて簡単な説明を付けてユーザーに通知し、適切な時間変換Webサービスにリンクして、人々を支援することができます。理想的には、すべてのタイムスタンプに現地時間に変換するオプションが必要です。
すべての説明が終わったら、私がずっと部屋の象を無視してきたことに気付くはずです。それが、すでに実装した「カウントダウン」ソリューションです。「1日2時間45分47秒で」について混乱するようなことは何もありません（そして、それほどの精度が必要ないと思われる場合は、もう一度考えてみてください）。
確かに、私の経験では、静的なテキスト以外の贅沢はありませんでした。そのため、上に示した信じられないほどの混乱を処理する必要がありました（そしてそれは、その始まりにすぎません！南半球では、DSTは後方に向かっていますか？）しかし、あなたのユースケースでは、混乱の可能性が最も少ないソリューションのように聞こえます。通常は「24時間以内」からカウントダウンしているのに、「2時間以内」と「25時間以内」のイベントについて質問するスレッドが1年に2つあるかもしれませんが、それだけです。