私は、ユーザーが時間範囲を指定できるようにしたいと思う状況があります。ここでは、時間は特定の週に存在する相対的な範囲です。ユーザーは月曜日午後5時から火曜日午前1時を選択することができます。それは、「人の仕事シフトは何時」のようなものだと考えてください。一週間の時間を保存する最も良い方法
私の最初の反応は、「相対的な」時間を保存できることです。週が月曜日00:00:00に始まると仮定すると、正午の月曜日は86400/2 = と表示されます。私はこの方法が本当に好きではありません。なぜなら、タイムゾーンを少し難しくするからです。
これを実行するための「最良の」方法がありますか？ MySQLにはこれを具体的に扱う何らかのデータ型がありますか？
この「Perl」と「MySQL」は、このアプリケーションで使用する予定ですので、このタグを付けましたが、その答えは技術的に特定のものである必要はありません。
最適な答えは、データのダウンストリームで何をするかによって多少異なります。
しかし、（私のMySQLが錆びているので、テーブルの構文Sybaseのを - 申し訳ありません）私はどんなハックを回避し、簡単なアプローチを行うことをお勧め
CREATE TABLE weekday_ranges (
start_dow int, -- 0-6 or 1-7 depending on what's easier downstream
start_hour int, -- 0-23
start_minute int, -- 0-59
-- Add seconds/micorseconds as needed
end_dow int,
end_hour int,
end_minute int
)
別のアプローチは、日曜日からのオフセット（秒単位）を格納することです00:00、開始と終了の両方のオフセット。これは利点を提供します（たとえば、複雑な式の代わりに<と>の演算子のみ）。
私は私の質問に私が示唆したことである代替アプローチを好むと思います。私は、あなたのソリューションはアプリケーションレベルでうまくいくと思いますが、それはクエリとして妨げられています。 – GoldenNewby
@ GoldenNewby - これはクエリとして機能しますが、秒オフセットアプローチと比較して間違いなく疑似的に醜いです。それが勝った場所は、両方の格納と検索で毎週 "日曜日00:00"エポック＃を計算する必要はありません – DVK
開始時刻と終了時刻をそれぞれ1つのフィールドに（部品に分解されているのではなく）格納すると、フィールドのインデックスが作成されます。そうでなければ、それほど大きな違いはありません。
実際には、解決できないタイムゾーンの問題があります。スイッチの最初の2amと2番目の2amを区別する方法がありません（これは、パーツがPerlまたはSQLで1つの値に組み立てられるかどうかを選択することになります）。 DSTから入力を処理するための情報が不足しています。
タイムゾーンの問題に関する私の考えは、2AMが常に2AMを参照するということです。週の所要時間を秒単位で見て、ある週にタイムゾーンが発生するかどうかを判断できます。 – GoldenNewby
@ GoldenNewby、それは何も解決しません。あなたはまだ最初の午前2時を参照する手段を持っていません。今、それはあなたがする必要はないかもしれませんが、あなたはまだ多くのことを言う必要はありません。 – ikegami
@GoldenNewby、ある週にタイムゾーンの変更が発生するかどうかは、あなたの質問とは関係がないので、なぜあなたがそれを持ち出すのか分かりません。それを演じると、何の問題も複雑になります。 – ikegami
クエリが「月曜日5 PM - 火曜日1 AM」を「UTC datetime range」に変換しないのはなぜですか？ – kev
私は間違っているかもしれませんが、変換されたUTC日時範囲は絶対日付ではありませんか？私は "1PM - 8PMの毎週火曜日"を表現する方法を保存していますが、 "この特定の火曜日は1PM - 8PM"ではありません。 – GoldenNewby
あなたはどのフォーマットが最良かを尋ねますが、どのようなフォーマットが使用されるかを指定していないので、何が最良かを判断できる情報を提供していません。どのような種類のクエリでこのデータを調べますか？ – ikegami