1

オーストラリアのシドニーにある私の場所。私が説明する日付は、英国またはオーストラリアの日付形式になります。

次の点に注意してください。

  • 2010-04-15 04:30:00.000 => 15/04/2010 14:30:00 EST (英国の日付形式 - 10 時間追加)
  • 2010-11-05 01:00:00.000 => 05/11/2010 12:00:00 EST (英国の日付形式 - 11 時間追加)

これらの時間はどちらも UTC 形式でデータベースから取得され、+10 時間または +11 時間が適用されるかどうかを Web レベルで計算します。

オーストラリアでは、夏時間 (DST) への移行日は年によって異なります。移行日は通常、4 月上旬と 10 月下旬です。

では、Web 計算はどの程度正確でしょうか? 今年の移行日が数日後 (たとえば 2010 年 3 月 4 日) であるが、Web 計算が固定の日付 (たとえば 2010 年 1 月 4 日) に基づいている場合、その間の日数は次のようになります。表示時に1時間ずれる（月の特定の日に固定された計算の性質による）？

移行日は事前に決定されておらず、実際に公開されていると思います。その仮定は本当ですか？

そうでない場合 (DST の日付が事前に決定されていることを意味します)、Web レベルの外で ( SQL/データベース レベルで) 計算を行うことはできますか?

データベースはSQL Server 2005で、レポート定義言語 (RDL)を使用してフィールドを UTC 時間で表示しています。SQL/データベース レベルが最適な方法ではない場合、+10 または +11 を計算し、それに応じて時刻をフォーマットして正しい時刻を表示するにはどうすればよいですか?

ありがとうございました。

4

3 に答える 3

2

データベースは悪い選択です。それを解決するには、C# や .net よりも情報が少なくなります。.net は、パッチによって定期的に最新の状態に保たれるレジストリを使用します。SQL Server には、日付範囲とオフセットを含むテーブルが必要です。

トランジションは、スケジューリング（フライト、電車など）のために固定されています。IIRC は、最近オーストラリアでいくつかのオリンピックのために急遽変更されただけで、世界中で混乱を引き起こしました。2007 年に米国は変化しましたが、これは事前に知られていたことです。

固定では、日付が変わっても固定される「最後の日曜日」タイプです。

私はそれをWebコードに残します.DBはあなたの発信者がどこにいるかを知りません.例えば、Webサイトはそれを解決することができます.

于 2010-11-10T05:10:33.153 に答える
1

問題は、このアプリを作成した人が、UTC、その価値、およびその使用方法をよく理解していないことです。データベースはデータの正しい場所ですが、システムは意図したとおりに UTC を使用していません。

UTC を使用する場合は、すべての日付演算で UTC を使用する必要があります。データベース内。現在、保存された UTC を使用してから、他のレイヤー (第 2 層か第 3 層かは関係ありません) で変換しています。他のライブラリ。半分は UTC で、半分は別のものです。2010 年 2 月 15 日から今日までの DATEDIFF() のように、歴史的な日付を考慮しましたか?

これにより、オーストラリアまたはグリーンランドでの DST に関する懸念が解消されます。そして、切り替えが実際に行われる日時に関する懸念。誰もがその特定の日にグリニッジ標準時を使用しています。

UTCで、dbですべての日付計算を行います。そして、結果（のみ）をローカルタイムゾーンで表示します。これは、ユーザーに基づいたWebレイヤーです。

多くのシステムでは、この最後のステップが完全に削除され、ユーザーのタイム ゾーンに関係なく、UTC のみで表示されます。

于 2010-11-11T08:22:28.610 に答える
0

データベースは DST を処理できます。そのタイムゾーン変換関数を使用して、日付を保存したゾーンから、ユーザーに取得したいゾーンに移動します。

MySQL には CONVERT_TZ() がありますが、他の RDBMS に何があるかはわかりません。

于 2010-11-10T04:28:08.927 に答える