実装は絶対に重要です。あるデータベースまたは別のデータベースに対するクエリは、そのデータベースが日付/時刻の値を格納する方法によって大きく異なります。質問を編集して、使用しているテクノロジーに固有のものにすることをお勧めします。可能であれば、いくつかのコードを示してください。
ただし、一般的には 2 つの概念を混同しているため、おそらくそれらを精神的に分離するように努める必要があります。
何かが起こった瞬間、イベント時間は、DateTime の組み合わせ値によって測定できます。これは、UTC として、またはオフセットがわかっている UTC からのオフセット値として表されます。これは、「瞬間時間」、「ユニバーサル時間」、または「物理時間」と呼ばれることがよくあります。
「今日」、「昨日」、「2013 年 3 月 29 日」など、ローカルで日付と時刻について話すときに付ける値。時間がある場合でも、カレンダー上の 1 日のほんの一部について話しているだけです。これは、「Calendar Time」、「Local Time」、または「Civil Time」と呼ばれることがよくあります。
瞬時時間でいつでもクエリと計算を行うことができます。それは明白です。しかし、「今日」という概念は無意味です。一日の終わりと次の日の始まりをマークするオブザーバーはありません。(オブザーバーがロンドンにいると主張する人もいるかもしれませんが、BST 中はそうではありません。)
Calendar Time は、日レベルの精度と 1 つのオブザーバーしかない場合のクエリまたは計算にのみ適しています。そのため、通常、イベントなどの普遍的なものをうまく表現できません。
元の質問に戻りましょう。あなたが言った:
2013 年 3 月 23 日から 2013 年 3 月 24 日までのすべてを照会したい
そこに問題があります。コンテキストは何ですか?誰のカレンダーの日付について話しているのですか? 3 月 23 日と言ったとしても、おそらく 3 月 23 日の午前 0 時 (UTC) から 3 月 24 日の午前 0 時 (UTC) を意味するわけではありません。おそらく、他のカレンダーの真夜中のことを意味しているでしょう。
毎日が 24 時間の長さではないことに注意してください。タイム ゾーンが夏時間 (または夏時間) のオンとオフを切り替えると、1 日の長さが 23 時間または 25 時間になる場合があります。
じゃあ何をすればいいの?まず、タイム ゾーン データベースが必要です (たとえば、IANA/Olson/TZ/TZDB/ZoneInfo データベースなど) 。これは Ruby で実装されたものです。
ここで、ユーザーのローカル タイム ゾーンを知る必要があります。つまり、クエリ結果を表示している質問をしている人物です。これには、独自のアプリケーション ロジック、おそらくセレクターまたはピッカーが含まれます。これが Web アプリの場合は、この地図ベースのタイムゾーン ピッカーまたはjsTimeZoneDetectを参照してください。
イベントは常に瞬時に保存する必要があります。イベントを UTC として保存するとしましょう (オフセットを使用することもできますが、ここでは無視します)。
そのため、ユーザーが希望する日付範囲について知る必要があります。クエリの開始日と終了日が UTC のどの時刻にマップされるのでしょうか? たとえば、Asia/Calcutta
タイム ゾーンを使用してインドにいるとします。23-mar-2013 00:00 - 24-mar-2013 00:00
をUTC に相当するものに変換し22-mar-2013 18:30 - 23-mar-2013 18:30
ます。
次に、これらの UTC DateTime 値を使用してデータベースにクエリを実行できます。
ユーザーに結果を返すとき、UTC を現地時間に戻して、ユーザーが見ている結果を理解できるようにする必要があります。
また、この投稿の多くの優れた提案もお読みください。