In Postgres 9.5 war ich überrascht, das unten gezeigte Ergebnis zu sehen, während ich mit dem Jahr 0001(ohne Jahr Null 0000) experimentierte .

Offset von `-07:52:58`?

Ein Beispielcode. Beachten Sie, dass ich gemischte Verwendung von TIMESTAMP WITH TIME ZONEund TIMESTAMP WITHOUT TIME ZONE, also lesen Sie sorgfältig.

SET TIME ZONE 'America/Los_Angeles' ;

SELECT (TIMESTAMP WITH TIME ZONE '2015-01-01 00:00:00.0', 
        TIMESTAMP WITH TIME ZONE '0001-01-01 00:00:00.0Z', 
        TIMESTAMP WITHOUT TIME ZONE '0001-01-01 00:00:00.0Z') ;

("2015-01-01 00:00:00-08","0001-12-31 16:07:02-07:52:58 BC","0001-01-01 00:00:00")

Ich bin von diesem zweiten Wert überrascht: 0001-12-31 16:07:02-07:52:58 BC. Ich verstehe, dass wir acht Stunden zurückgehen müssen, da wir America/Los_Angelesacht Stunden hinter UTC mit einem Offset von liegen -08:00. Aber stattdessen ist -08:00der Versatz -07:52:58. Warum?

Kein Problem unter UTC

Kein solches Problem bei der Eingabe von Daten unter UTC.

SET TIME ZONE 'UTC' ;

SELECT (TIMESTAMP WITH TIME ZONE '2015-01-01 00:00:00.0',  
        TIMESTAMP WITH TIME ZONE '0001-01-01 00:00:00.0Z', 
        TIMESTAMP WITHOUT TIME ZONE '0001-01-01 00:00:00.0Z');

("2015-01-01 00:00:00+00","0001-01-01 00:00:00+00","0001-01-01 00:00:00")

Kein Jahr Null

Übrigens scheint der Datumsanteil korrekt zu sein. Es scheint, als gäbe es kein Jahr 0000, da es der Dreh- und Angelpunkt zwischen den Epochen „BC“ und „AD“ ist. Nehmen Sie den ersten Moment des Jahres 0001, subtrahieren Sie eine Stunde und Sie erhalten das Jahr 0001 BC- also kein Jahr Null.

SET TIME ZONE 'UTC' ;

INSERT INTO moment_  -- TIMESTAMP WITH TIME ZONE.
VALUES ( TIMESTAMP '0001-01-01 00:00:00.0Z' - INTERVAL '1 hour' ) ;

SET TIME ZONE 'UTC' ;

TABLE moment_ ;

Das Ergebnis ist das Jahr 0001 BC, also springen wir von 0001zu 0001 BC; kein Jahr Null 0000.

"0001-12-31 23:00:00+00 BC"

— Basil Bourque
quelle

Auch ein schönes Video über den Wahnsinn der Zeitzonen

— billinkc

Der Dreh- und Angelpunkt zwischen BC und AD ist das Jahr 1. Es ist entweder das Jahr 1 oder das Jahr -1. Es ist nur, wie Jahre ursprünglich benannt sind. Das Jahr 0 existiert nicht (oder ist undefiniert, da es sich eher um ein Definitionsproblem als um ein existenzielles handelt).

— Slebetman

Erinnern Sie sich an die Feierlichkeiten von 2000, als einige pedantische Leute sagten, dass das zweite Jahrtausend technisch im Jahr 2001 und nicht im Jahr 2000 beginnt? Deshalb. Die Jahre beginnen mit 1 und nicht mit 0. Und das Jahr vor Jahr 1 ist Jahr 1 v. Chr. (

— Dh

@slebetman, das vom verwendeten Kalender abhängt. Der proleptische Gregorianer hat sowohl eine Form, die 0 als Jahr vor 1 CE verwendet, als auch eine Form, die 1 BCE unmittelbar vor 1 CE platziert (ISO 8601 unterstützt beide 0000als gültigen Jahreswert, besteht jedoch nicht darauf, ob er verwendet wird oder nicht) ). Es ist wahr, dass PostgreSQL das Formular ohne Jahr 0 verwendet, aber Sie können nicht "Jahre beginnen eine 1, nicht 0" als eine Art universelle Tatsache angeben. Es ist einfach, zwischen ihnen zu übersetzen, z. B. für astronomische Daten. (Das dritte Jahrtausend begann immer noch in beiden Richtungen im Jahr 2001, da es das dritte Jahrtausend seit dem 1. Jahrhundert nach Christus war.)

— Jon Hanna,

@ JonHanna: Zu der Zeit verwendete jedoch niemand irgendeine Form des proleptischen gregorianischen Kalenders. Ich denke, es ist fair, den julianischen Kalender hier zu privilegieren - der kein Jahr Null hat.

— Kevin

Am 18. November 1883 um 12:00 Uhr (Neuzeit) wurde die Standardzeit von den amerikanischen Eisenbahnen übernommen.

Dies bedeutet, dass Los Angeles vor dieser Zeit die tatsächliche Ortszeit verwendete, basierend auf der mittleren Sonnenzeit. Danach wurde es in seine lokale Zeitzone verschoben, die sich geringfügig von der vorherigen Zeit unterschied, da sie einen integralen Stundenversatz zur Greenwich Mean Time darstellte.

Möchten Sie mehr wissen?

Laden Sie die tzdata-Zeitzonendatenbank von IANA: Zeitzonen herunter .
Im Inneren finden Sie die Definitionen der (vielen) Zeitzonen, die im Laufe der Zeit viele Variationen aufweisen, sowie viele Kommentare, in denen angegeben ist, welche Änderungen wann und wo vorgenommen wurden. Es ist eine unterhaltsame Lektüre!
Wikipedia hat auch einige interessante Fakten in der Wikipedia: Zeitzonenseite in Bezug auf die Änderung vom 18. November 1883:

Eisenbahnzeit
... Die
Zeitmessung auf den amerikanischen Eisenbahnen in der Mitte des 19. Jahrhunderts war etwas verwirrt. Jede Eisenbahn verwendete ihre eigene Standardzeit, normalerweise basierend auf der Ortszeit ihres Hauptquartiers oder dem wichtigsten Endpunkt, und die Zugfahrpläne der Eisenbahn wurden unter Verwendung ihrer eigenen Zeit veröffentlicht. Einige Kreuzungen, die von mehreren Eisenbahnen bedient wurden, hatten für jede Eisenbahn eine Uhr, die jeweils eine andere Zeit angab.
... Dowds System wurde von den amerikanischen Eisenbahnen nie akzeptiert. Stattdessen implementierten die amerikanischen und kanadischen Eisenbahnen eine Version, die von William F. Allen, dem Herausgeber des offiziellen Eisenbahnführers des Reisenden, vorgeschlagen wurde. Die Grenzen seiner Zeitzonen verliefen durch Bahnhöfe, oft in Großstädten. Beispielsweise verlief die Grenze zwischen der östlichen und der zentralen Zeitzone über Detroit, Buffalo, Pittsburgh, Atlanta und Charleston. Es wurde am Sonntag, dem 18. November 1883 , eingeweiht , auch "Der Tag der zwei Mittagsstunden" genannt , als jede Bahnhofsuhr zurückgesetzt wurde, da in jeder Zeitzone die Standard-Mittagszeit erreicht war. Die Zonen wurden als Intercolonial, Eastern, Central, Mountain und Pacific bezeichnet. ...

Beachten Sie auch, dass dies nicht spezifisch für Postgresql ist. Dies gilt für jede Software oder jedes Betriebssystem, die / das die tzdata-Datenbank verwendet (obwohl natürlich viele auf Daten nach 1970 oder nach 1901 beschränkt sind, so dass 1883 unerreichbar ist, aber es gibt viele, viele andere Anpassungen überall auf der Website andere Zeiten).

— jcaron
quelle

Warum hat die Zeitzone im Jahr 0001 in Postgres so einen verrückten Versatz von UTC?

Offset von -07:52:58?

Kein Problem unter UTC

Kein Jahr Null

Offset von `-07:52:58`?