Jak poznać strefę czasową znacznika czasu w postgresql 8.3

Question

Używam PostgreSQL 8.3 i chciałbym poznać strefę czasową określonego znacznika czasu (kolumna w tabeli).

W dokumentacji znalazłem słowa kluczowego "timezone"

Ale ja nie rozumiem, jak zastosować je w kolumnie tabeli. Czy to możliwe ?

Answer 1

Zakładam, że masz kolumnę o nazwie ct, która ma typ TIMESTAMPTZ w tabeli t. Następnie możesz użyć:

SELECT EXTRACT(TIMEZONE FROM ct) FROM t; 

, aby uzyskać przesunięcie strefy czasowej w sekundach. To, że daje 3600 z UTC/GMT to znaczy albo GMT+1CET, czy cokolwiek innego. Zwrócona wartość zależy od ustawienia TIMEZONE.

Sample (mieszkam w Niemczech, rzeczywiste ist stref czasowych GMT+1/CET):

test=# select '2008-01-01 12:00:00 GMT+5'::timestamptz; 
     timestamptz  
------------------------ 
2008-01-01 18:00:00+01 

test=# set timezone to 'gmt'; 
SET 
test=# select '2008-01-01 12:00:00 GMT+5'::timestamptz; 
     timestamptz  
------------------------ 
2008-01-01 17:00:00+00 

Jak można zobaczyć to zawsze wyprowadza nic skonfigurowanej strefy czasowej. Tak więc przesunięcie, które otrzymasz z EXTRACT(TIMEZONE FROM ...) zależy od ustawienia TIMEZONE. Strefa czasowa podana na INSERT została utracona, ponieważ nie warto jej zapisywać. Liczy się to, że wszystko jest poprawne i nie powinno zależeć od ustawienia TIMEZONE. PostgreSQL robi to bardzo dobrze.

Answer 2

"PostgreSQL robi to bardzo dobrze."

Bardzo podoba mi się PostgreSQL, ale w tej konkretnej funkcji nie robi tego dobrze. Strefa czasowa jest nie tylko przesunięta względem GMT. Strefa czasowa jest ściśle związana z zasadami politycznymi, które wymagają oszczędzania czasu. Ponieważ istnieje wiele stref czasowych z tymi samymi przesunięciami i różnymi regułami czasu letniego - kiedy PG zapomina o oryginalnej strefie czasowej, traci informacje.

Osobiście przechowuję oryginalną strefę czasową osobno dla dat, które mają znaczenie w formularzu "Ameryka/Nowy_Jork". Jeśli ktokolwiek ma lepsze rozwiązanie - jest mile widziany.

Answer 3

Ponieważ timestampz jest zapisywany przez chwilę w czasie ZULU/GMT, który nigdy nie zmienia jego przesunięcia (ponieważ jest to odniesienie), nie jest konieczne nagrywanie strefy czasowej. Musisz tylko dodać/odjąć przesunięcie do przesunięcia strefy czasowej GEOPOLITYCZNEJ w OCZEKIWANIU, OBECNEJ lub PRZYSZŁOŚCI.

You DO musisz znać dokładną strefę czasową GEOPOLITYCZNĄ obowiązującą w miejscu, w którym obecnie obowiązuje ta godzina, dla celów PAST i OBECNYCH.

Dla przyszłych przypadków w czasie może to być bardziej problematyczne. Powinno jednak nadal działać. Pomyśl o zachodzie słońca. Jeśli w niektórych lokalizacjach Ziemia ma zachód słońca o północy czasu ZULU (gdzieś nad Oceanem Atlantyckim lub północną Kanadą na Alasce w zimie na półkuli północnej) i przyjmuje się, że jest to godzina 20.00 (przesunięcie o 4: 00) w tym miejscu o od momentu zarejestrowania go w systemie i zapisania go jako "zimową datę w przyszłości 20:00" zostanie zapisany w bazie danych jako 24:00 GMT.

teraz, że lokalizacja na ziemi dostaje włosy jego * SS i kciuki jego nos w geograficznym powiązanej liczenia czasu i wzywa ich strefa czasowa - „+11: 55”.Więc dla nich, kiedy jest północ w Anglii (GMT północ), CHCĄ nazwać to 11:55, całkowicie ich wybór. Kiedy dowolny komputer chce wyświetlać tę datę w przyszłości dla tej lokalizacji (to jest tej geopolitycznej strefy czasowej), będą ją nazywać 11:55, nawet jeśli zachodzi słońce. I, oczywiście, będzie to dzień AHEAD dnia, w którym to zaplanowałeś :-) Ich problem.

Answer 4

W Postgrezu oryginalna strefa czasowa wejścia jest tracona, nawet jeśli zapisano wartość datetime w kodzie czasowym ze strefą czasową typu danych.

Wada:
powiedzieć, czy mam danych datetime (wraz z informacją o czasowej), gdy ludzie używają ich Aplikacja Facebook na całym świecie. Teraz przechowuję te wartości w kodzie czasowym z typem strefy czasowej. Pewnego losowego dnia chcę zobaczyć, jak ciężko ludzie używają swojej aplikacji FB rano w porównaniu do nocy i jeśli ten sam trend jest widoczny w różnych krajach. Ale czekaj, nie mam już informacji o strefie czasowej. Siedząc w D.C., widzę, jak aktywność toczyła się po całym świecie, kiedy było 10 rano EST.

Zaleta:
przypadku porównywania dwóch źródeł danych ze znacznikiem czasu w samej strefie czasowej, ale jeden był przechowywany jak co lokalny zegarek pokazywał podczas gdy inne przechowywane przez przekształcenie go do UTC. Tutaj możesz po prostu zapisać znacznik czasu w typie timestamptz i określić strefę czasową, do której należy, a następnie łatwo je porównać. Na przykład:
Aktywność w strefie czasowej PST została zarejestrowana pod numerem 2014-10-19 10:23:54. Teraz dwa osobne źródła danych przechowują je osobno. Datasource1 zapisał go jako 2004-10-19 10:23:54 PST, Datasource2 zapisał jako 2014-10-19 18:23:54 UTC. Jeśli są one przechowywane w timestamptz typu danych, pokaże w tym samym czasie, gdy robisz

SELECT datasource1.time, datasource2.time