レコードの名前はdbで、レコードはいくつかあります。 これは列ライン以下ユーザーごとのUTCによるタイムゾーンの変更の計算
Id(uniqueidentifier)
SubmittedDate(DateTime)
RecordNumber(uniqueidentifier)
レコードの一つの列を表すの下、
Id RecordNumber SubmittedDate
'CD458C6D-9F45-41C1-85D8-E3D8287A82B4', 'EBB5DE3A-4B14-4112-AF51-0F8367FE3383' '2016-11-02 08:27:17.300'
ユーザがタイムゾーンのいずれかからレコードを提出することができています。ベストプラクティスの一環として、DateTimeをUTCで保存しています。 したがって、ユーザーごとにtimezoneをdatetimeをUTCに変換してテーブルを保存しています。
ここで、結果は、ユーザーが日付順に提出した件数として返さなければなりません。 ユーザーごとにタイムゾーンごとにレコードを返す必要があります。
ユーザーが22Nov2016の午前1時に10件のレコードを提出し、21Nov2016に提出されたレコードがなく、ユーザーがISTタイムゾーンに属している場合。 サーバー側では、我々はISTに22Nov2016一時00分AMに変換され、同じユーザーのクエリは、我々が追加された日11月24日の最後の5日間のレコードが現在のユーザーのタイムゾーンすなわちのオフセットを取得した場合21Nov2016 9：00 PM UTC
としてそれを保存します（+5：30）からSubmittedDate列に移動し、それに従ってレコードを取得します。 それで、ユーザーがタイムゾーンごとに提出したレコードの正しい数を取得する必要があります。 SubmittedDate日付にUTCオフセットを追加した後、22Nov2016の日付のレコード数が10になります。
このソリューションは、夏時間の間、つまりタイムゾーンがPSTからPDTに、またはその逆に変換されるときにUTCオフセットに変更があった場合は機能しません。ユーザーがrecods
を提出したときは、ユーザーの表に、この我々が追加したタイムゾーンの列を克服するために
ID（UNIQUEIDENTIFIER） SubmittedDate（日時） RecordNumber（UNIQUEIDENTIFIER） SubmittedTimeZone（varchar型）
ので、 a）夏時間がオンのタイムゾーンからのユーザークエリレコードと、夏時間があったときに提出されたレコードが提出されたとき、オフセットするものは何も実行していません。
b）夏時間保存が設定されているタイムゾーンからユーザクエリレコードが送信され、その場合に夏時間がオフになっている場合は、オフセットに1時間を追加しています。
c）夏時間がオフになっているタイムゾーンからのユーザークエリレコードと、夏時間がある場合は送信されたレコードが送信された場合、オフセットに-1時間を追加しています。
d）夏時間がオフになっているタイムゾーンからのユーザークエリレコードがあり、夏時間がオフになっているときに送信されたレコードも送信されたとき、オフセットするものは何もしません。
このタイムゾーン/夏時間の処理方法は、タイムゾーンごとに適切ですか？
注：私たちは、夏時間が「夏時間」「アラスカ夏時間」のような 、「東部夏時間の時間」として最後の二つの言葉を持っている列SubmittedTimeZone値でオンにしたがある場合にも提出された提出したレコードを識別しています
ここで、タイムゾーンが別のタイムゾーンでオフになっていると、夏時間がオンになっている可能性があります。おそらく、送信された日付と送信されたタイムゾーンの列に基づいて、ユーザーにタイムゾーンを要求するためのオフセットを計算する必要があります。