Nejprve byste měli použít timestamptz
místo timestamp
při práci s více časovými zónami. Tento problém by se zcela vyhnul.
Podrobnosti:
můžete použijte AT TIME ZONE
vytvořit jako @NuLo navrhuje
, může dokonce fungovat, ale ne přesně tak, jak je popsáno.
AT TIME ZONE
převede typ timestamp
(timestamp without time zone
) na timestamptz
(timestamp with time zone
) a naopak. reprezentace textu z timestamptz
hodnota závisí na aktuálním nastavení časového pásma v relaci, ve které příkaz spustíte. Tyto dva timestamptz
hodnoty jsou 100 % identické (označují stejný časový okamžik):
'2015-09-02 15:55:00+02'::timestamptz
'2015-09-02 14:55:00+01'::timestamptz
Ale textová reprezentace není . Displej je pro různá časová pásma. Pokud vezmete tento řetězcový literál a vložíte jej do timestamp
typu, část časového pásma je pouze ignorována a skončíte s jiným hodnoty. Pokud tedy spustíte COPY
příkaz v relaci se stejným nastavením časového pásma jako vaše původní timestamp
hodnoty jsou pro, navrhovaná operace proběhne do práce.
Čistým způsobem je však vytvořit správné timestamp
hodnoty pro začátek použitím AT TIME ZONE
dvakrát :
SELECT event AT TIME ZONE 'my_target_tz' AT TIME ZONE 'my_source_tz', ...
FROM logtable
ORDER BY event desc;
'my_target_tz'
je "vaše vlastní časové pásmo" a 'my_source_tz'
časové pásmo cloudového serveru v příkladu. Chcete-li se ujistit, že je dodržován letní čas, použijte názvy časových pásem , nikoli zkratky časových pásem. Dokumentace:
Související:
- Účtování letního času v Postgresu při výběru naplánovaných položek
- Názvy časových pásem se stejnými vlastnostmi dávají při použití na časové razítko jiný výsledek
Nebo, ještě lépe, použijte timestamptz
všude a funguje správně automaticky.