In Postgres 9.5, sono stato sorpreso di vedere il risultato visto sotto mentre sperimentavo l'anno 0001(nessun anno zero 0000).

Offset di `-07:52:58`?

Qualche codice di esempio. Nota che ho mescolato l'uso di TIMESTAMP WITH TIME ZONEe TIMESTAMP WITHOUT TIME ZONE, quindi leggi attentamente.

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")

Mi sorprende che secondo valore: 0001-12-31 16:07:02-07:52:58 BC. Capisco che dobbiamo tornare indietro di otto ore, così come America/Los_Angelesotto ore dietro UTC con un offset di -08:00. Ma invece -08:00dell'offset è -07:52:58. Perché?

Nessun problema con UTC

Nessun problema di questo tipo durante l'immissione dei dati in 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")

Nessun anno zero

A proposito, la parte della data sembra essere corretta. Sembra che non ci sia un anno 0000, essendo questo il punto di snodo tra le epoche "BC" e "AD". Prendi il primo momento dell'anno 0001, sottrai un'ora e ottieni l'anno 0001 BC, quindi nessun anno zero.

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_ ;

Il risultato è l'anno 0001 BC, quindi saltiamo da 0001a 0001 BC; nessun anno zero 0000.

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

— Basil Bourque
fonte

Inoltre, un bel video sulla follia dei fusi orari

— billinkc,

Il punto di articolazione tra BC e AD è l'anno 1. È l'anno 1 o l'anno -1. È proprio come gli anni vengono chiamati in origine. L'anno 0 non esiste (o meglio, non è definito poiché è più un problema di definizione piuttosto che esistenziale).

— Slebetman,

Ricordi le celebrazioni del 2000, quando alcuni pedanti affermarono che il secondo millennio inizia tecnicamente nell'anno 2001, non nel 2000? Ecco perchè. Gli anni iniziano a 1, non a 0. E l'anno prima dell'anno 1 è l'anno 1 a.C. (cioè l'anno -1)

— slebetman

@slebetman che dipende dal calendario in uso. Il proletico gregoriano ha sia una forma che usa 0 come l'anno prima del 1 ° CE, sia una forma che pone 1 BCE immediatamente prima di 1 CE (ISO 8601 supporta entrambi nell'avere 0000un valore dell'anno valido ma non insistendo sull'opportunità o meno ). È vero che PostgreSQL utilizza il modulo senza anno 0, ma non si può affermare che "anni iniziano a 1, non 0" come se fosse una sorta di fatto universale. È facile tradurli tra loro per es. Dati astronomici. (Il terzo millennio iniziava comunque nel 2001, poiché rimase il terzo millennio dal 1 ° CE)

— Jon Hanna,

@JonHanna: A quel tempo nessuno stava usando alcuna forma del prolettico calendario gregoriano, quindi penso che sia giusto privilegiare qui il calendario giuliano, che non ha un anno zero.

— Kevin,

Il 18 novembre 1883 alle 12:00 (ora nuova), le ferrovie americane adottarono l'ora standard.

Ciò significa che prima di allora, Los Angeles utilizzava l'ora locale effettiva, in base all'ora solare media. Successivamente, è stato spostato nel suo fuso orario locale, che, essendo un offset integrale delle ore dal Greenwich Mean Time, era leggermente diverso dall'ora precedente.

Voglio sapere di più?

Scarica il database del fuso orario tzdata da IANA: Fusi orari .
All'interno, troverai le definizioni dei (molti) fusi orari, che hanno molte variazioni nel tempo, insieme a molti commenti che descrivono in dettaglio quali modifiche sono state apportate e quando. È una lettura divertente!
Wikipedia ha anche alcuni fatti interessanti, nella pagina Wikipedia: Time zone , riguardo al cambiamento del 1883 del 18 novembre:

Tempo delle ferrovie
... Il
cronometraggio delle ferrovie americane a metà del XIX secolo era alquanto confuso. Ogni ferrovia utilizzava il proprio orario standard, di solito in base all'ora locale della sua sede o capolinea più importante, e gli orari dei treni della ferrovia venivano pubblicati secondo il proprio orario. Alcuni incroci serviti da diverse ferrovie avevano un orologio per ciascuna ferrovia, ognuna delle quali mostrava un orario diverso.
... Il sistema di Dowd non fu mai accettato dalle ferrovie americane. Invece, le ferrovie statunitensi e canadesi hanno implementato una versione proposta da William F. Allen, l'editore della guida ferroviaria ufficiale del viaggiatore. I confini dei suoi fusi orari attraversavano le stazioni ferroviarie, spesso nelle principali città. Ad esempio, il confine tra i suoi fusi orari orientali e centrali attraversava Detroit, Buffalo, Pittsburgh, Atlanta e Charleston. Fu inaugurato domenica 18 novembre 1883 , chiamato anche "Il giorno dei due mezzogiorno" , quando ogni orologio della stazione ferroviaria fu ripristinato come mezzogiorno standard veniva raggiunto all'interno di ogni fuso orario. Le zone furono chiamate Intercolonial, Eastern, Central, Mountain e Pacific. ...

Si noti inoltre che questo non è specifico di Postgresql. Questo è valido per qualsiasi software o sistema operativo che utilizza il database tzdata (anche se ovviamente molti saranno limitati a date post 1970 o post 1901, quindi il 1883 è fuori portata, ma ci sono molte, molte altre regolazioni ovunque tempi differenti).

— jcaron
fonte

Perché il fuso orario ha un offset così folle rispetto a UTC nell'anno 0001 in Postgres?

Offset di -07:52:58?

Nessun problema con UTC

Nessun anno zero

Offset di `-07:52:58`?