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.