Całkowite ignorowanie stref czasowych w Rails i PostgreSQL

Wszystkie daty i godziny uwzględniające strefę czasową są przechowywane wewnętrznie w UTC. Są konwertowane na czas lokalny w strefie określonej przez TimeZone parametr konfiguracyjny przed wyświetleniem na kliencie.

Przykład w psql:

db=# SELECT timestamptz '2012-03-05 20:00+03';
      timestamptz
------------------------
 2012-03-05 18:00:00+01

Co się tutaj stało?
Wybrałem dowolne przesunięcie strefy czasowej +3 dla literału wejściowego. Dla Postgresa jest to tylko jeden z wielu sposobów wprowadzania znacznika czasu UTC 2012-03-05 17:00:00 . Wynik zapytania jest wyświetlany dla aktualnego ustawienia strefy czasowej Wiedeń/Austria w moim teście, który ma przesunięcie +1 zimą i +2 w okresie letnim („czas letni”, DST). Więc 2012-03-05 18:00:00+01 ponieważ czas letni zaczyna się dopiero później.

Postgres natychmiast zapomina o literale wejściowym. Zapamiętuje tylko wartość typu danych. Podobnie jak w przypadku liczby dziesiętnej. numeric '003.4' lub numeric '+3.4' - oba dają dokładnie taką samą wartość wewnętrzną.

AT TIME ZONE

Jedyne, czego teraz brakuje, to narzędzie do interpretacji lub reprezentowania literałów znaczników czasu zgodnie z określoną strefą czasową. To tam AT TIME ZONE pojawia się konstrukcja. Istnieją dwa różne przypadki użycia. timestamptz jest konwertowany na timestamp i odwrotnie.

Aby wprowadzić timestamp UTC 2012-03-05 17:00:00+0 :

SELECT timestamp '2012-03-05 17:00:00' AT TIME ZONE 'UTC'

... co jest równoznaczne z:

SELECT timestamptz '2012-03-05 17:00:00 UTC'

Aby wyświetlić ten sam punkt w czasie, co EST timestamp (Czas wschodni standardowy):

SELECT timestamp '2012-03-05 17:00:00' AT TIME ZONE 'UTC' AT TIME ZONE 'EST'

Zgadza się, AT TIME ZONE 'UTC' dwa razy . Pierwszy interpretuje timestamp wartość jako (podany) znacznik czasu UTC zwracający typ timestamptz . Drugi konwertuje timestamp do timestamp w danej strefie czasowej 'EST' - co zegar ścienny wyświetla w strefie czasowej EST w tym momencie.

Przykłady

SELECT ts AT TIME ZONE 'UTC'
FROM  (
   VALUES
      (1, timestamptz '2012-03-05 17:00:00+0')
    , (2, timestamptz '2012-03-05 18:00:00+1')
    , (3, timestamptz '2012-03-05 17:00:00 UTC')
    , (4, timestamp   '2012-03-05 11:00:00'  AT TIME ZONE '+6') 
    , (5, timestamp   '2012-03-05 17:00:00'  AT TIME ZONE 'UTC') 
    , (6, timestamp   '2012-03-05 07:00:00'  AT TIME ZONE 'US/Hawaii')  -- ①
    , (7, timestamptz '2012-03-05 07:00:00 US/Hawaii')                  -- ①
    , (8, timestamp   '2012-03-05 07:00:00'  AT TIME ZONE 'HST')        -- ①
    , (9, timestamp   '2012-03-05 18:00:00+1')  -- ② loaded footgun!
      ) t(id, ts);

Zwraca 8 (lub 9) identyczne wiersze z kolumnami sygnatury czasowej o tej samej sygnaturze czasowej UTC 2012-03-05 17:00:00 . Dziewiąty rząd działa w mojej strefie czasowej, ale jest złą pułapką. Zobacz poniżej.

① Wiersze 6-8 ze strefą czasową nazwa i strefa czasowa skrót czas na Hawajach podlega DST (czasowi letniemu) i może się różnić, choć obecnie nie. Nazwa strefy czasowej, np. 'US/Hawaii' jest świadomy reguł czasu letniego i wszystkich historycznych zmian automatycznie, podczas gdy skrót taki jak HST to tylko głupi kod dla stałego przesunięcia. Może być konieczne dodanie innego skrótu dla czasu letniego/standardowego. Nazwa poprawnie interpretuje dowolne znacznik czasu w podanej strefie czasowej. skrót jest tani, ale musi być odpowiedni dla podanej sygnatury czasowej:

• Nazwy stref czasowych z identycznymi właściwościami dają różne wyniki po zastosowaniu do znacznika czasu

_{Czas letni nie należy do najjaśniejszych pomysłów, jakie kiedykolwiek wpadła ludzkość.}

② Wiersz 9, oznaczony jako załadowany footgun działa dla mnie , ale tylko przez przypadek. Jeśli jawnie rzutujesz literał na timestamp [without time zone] , każde przesunięcie strefy czasowej jest ignorowane! Używany jest tylko sam znacznik czasu. Wartość jest następnie automatycznie zmieniana na timestamptz w przykładzie, aby dopasować typ kolumny. W tym kroku timezone zakładane jest ustawienie bieżącej sesji, która jest tą samą strefą czasową +1 w moim przypadku (Europa/Wiedeń). Ale prawdopodobnie nie w twoim przypadku - co spowoduje inną wartość. W skrócie:nie przesyłaj timestamptz literały do ​​timestamp lub stracisz przesunięcie strefy czasowej.

Twoje pytania

SELECT * FROM tbl WHERE time_col > (now() AT TIME ZONE 'UTC')::time

SELECT * FROM tbl WHERE time_col > now()::time