Erhalte Sommerzeit Start und Enddatum für jede Zeitzone

Question

Ich sehe diese Frage ziemlich gefragt, aber sehe keine tatsächlichen Antworten (die meisten Lösungen sind speziell für US-Zeitzone).

Gibt es in SQL Server eine Möglichkeit, das Start- und Enddatum der Sommerzeit zu erhalten, wenn ein Jahr und eine Zeitzone angegeben werden?

Um es zusammenzufassen, ich suche jemand zu sehen, ob wurde mit einer Lösung für die folgenden zwei Prozeduren/Funktionen kommen:

datetime2 getDSTStartDate(@year int, @timeZone varchar) 
datetime2 getDSTEndDate(@year int, @timeZone varchar) 

Answer 1

Ich würde vermuten, dass es nicht wirklich möglich ist, genaue Tage zu bekommen. Es gibt Unterschiede zwischen Ländern und Regionen, und einige Orte beobachten die Sommerzeit überhaupt nicht. Es ist normalerweise zu einem vorgeschriebenen Datum und Uhrzeit, aber es kann sich während des Jahres ändern. Dann würden Ihre Datetime-Berechnungen keine Rolle spielen.

https://www.timeanddate.com/time/dst/2017.html

Siehe den zweiten Absatz auf dieser Seite:

Beachten Sie, dass diese Liste nicht endgültig sein könnte - Länder, Gebiete und Staaten manchmal Anpassungen vornehmen, die nur wenige Tage oder Wochen bekannt gegeben werden vor der Zeit ändern.

Diese Anweisung allein würde anzeigen, dass eine interne Datenbankfunktion so leicht obsolet werden könnte, dass es sinnlos wäre.

Sie konnten vergangene Daten tun, da sie bereits abgeschlossen wurden, aber wie die untenstehenden Diagramme zeigen, könnten sich zukünftige Daten, obwohl sie jetzt etwas gesetzt sind, ändern und wären unmöglich genau vorherzusagen.

** Country Counts For Last 3 Years ** 
--------------------------------------------------------------- 
|       **2017**       | 
--------------------------------------------------------------- 
|    DST Observance     |Count|Example| 
--------------------------------------------------------------- 
|No DST at all         | 172 | China | 
|At least one location observes DST    | 77 | USA | 
|All locations observe DST some part of the year| 67 | Iran | 
|Many locations observe DST part of the year | 9 | USA | 
|At least one location observes DST all year | 1 |  | 
|All locations observe DST all year    | 1 | Chile | 
--------------------------------------------------------------- 

--------------------------------------------------------------- 
|       **2016**       | 
--------------------------------------------------------------- 
|    DST Observance     |Count|Example| 
--------------------------------------------------------------- 
|No DST at all         | 171 | China | 
|At least one location observes DST    | 77 | USA | 
|All locations observe DST some part of the year| 69 | Iran | 
|Many locations observe DST part of the year | 8 | USA | 
--------------------------------------------------------------- 

--------------------------------------------------------------- 
|       **2015**       | 
--------------------------------------------------------------- 
|    DST Observance     |Count|Example| 
--------------------------------------------------------------- 
|No DST at all         | 168 | China | 
|At least one location observes DST    | 80 | USA | 
|All locations observe DST some part of the year| 70 | Iran | 
|Many locations observe DST part of the year | 9 | USA | 
|At least one location observes DST all year | 1 |  | 
|All locations observe DST all year    | 1 | Chile | 
--------------------------------------------------------------- 

HINWEIS: Aufgrund der oben genannten Unwägbarkeiten, und weil man auch programmatisch bestimmen haben würde, wo Ihre Benutzer ihre Eingabe gemacht, wäre es besser, nur speichern Datetimes in UTC oder ein anderes universelles Format und konsumiere es nach Bedarf. SQL ist möglicherweise nicht der beste Ort, um alles herauszufinden.