あなたはGMT（UTC）で正しい方向に進んでいると思います。特定の時点で発生する（または発生した）イベントがある場合は常に、UTCを正規のタイムスタンプ表現として使用します。UTCはDST規則の影響を受けないため、明確で明確な特定時点の表現として機能します。
イベントの日付/時刻を明確に表現するための戦略が決まったら、ユーザーから受け入れる（または表示する）のに最も理にかなっているタイムゾーンに基づいて日付/時刻をローカライズする問題を簡単に解決できます。イベントのタイムゾーンも知って保存する必要がありますが、実際のイベントの日付/時刻をUTCで保存しているため、関連性が高い場合は、ユーザーのタイムゾーンに簡単にローカライズできます。任意のユースケースでそれらに。
このローカリゼーションは通常、SDKによって提供されるタイムゾーンライブラリ（Javaにはjava.util.Calendarなど）またはサードパーティの拡張機能（Pythonにはpytzがあるなど）を使用して実行されます。PHPにも同等のものがあると思いますが、私はそのライブラリにあまり詳しくありません。
これらのライブラリは通常、 OlsonZoneinfoDBなどのルールデータベースの上に構築されます。これらのルールは非常に頻繁に変更される可能性があるため、特に真にグローバルなアプリケーションを開発している場合は、基盤となるデータベースの更新を常に把握しておく必要があります。ただし、これらは難解で曖昧なタイムゾーンルールを外部化するのに適しているため、（理論的には）ランタイム環境の大幅なアップグレードを実行したり、DSTルールのコードを大幅に変更したりすることなくルールデータベースを更新できます。特定のエリアの変更。
これは世界で最も簡単な問題ではなく、私たちがやらなければならない悪臭を放ちますが、一度それを数回行って、正確な特定時点の表現を保存することとローカリゼーションの問題との間の関心の分離を理解すると、それは第二の性質になります。
DST に対処するのは本当に苦痛です。
今後のイベントでは、GMT 時間ではなく、イベントが発生する場所と現地時間を保存する必要があります。これは、DST の開始時と終了時に政府が変更されることがあり (昨年米国で発生したばかりです)、イベントは現地時間ではなく GMT で変更されるためです。
Then if you need to notify when the event is occurring, every day collect the events for the next 24-48 hrs and convert their times to GMT then. To do that, you need a location-timezone database like this one. Get the GMT offset for each location at the time of the event and use that to convert the time to GMT, then you know exactly when the event will occur.
なぜユーザーに責任を転嫁しないのですか？アプリケーションを使用するには、登録する必要があると思います。
彼らのプロファイルで、彼らの時間オフセットを言ってもらうだけです. GMT + 2、GMT - 8 などのように、彼らは DST 設定がいつ変更されたかを知り、それに応じてプロファイルを更新します。
もちろん、これはユーザーベースによって異なります。彼らはアプローチを受け入れるかもしれないし、受け入れないかもしれない。