Re: Urgent PST time changing tonight
От | Steve Crawford |
---|---|
Тема | Re: Urgent PST time changing tonight |
Дата | |
Msg-id | 49B56A7F.6040004@pinpointresearch.com обсуждение исходный текст |
Ответ на | Urgent PST time changing tonight (DM <dm.aeqa@gmail.com>) |
Ответы |
Re: Urgent PST time changing tonight
Re: Urgent PST time changing tonight Re: Urgent PST time changing tonight |
Список | pgsql-admin |
DM wrote: > Hi All, > > PST time changing tonight, I am not sure if this is going to affect > the database.... IF you are up-to-date on your TZ files the database itself should be fine. But external processing is another matter - especially if you have processes that assume conventions from previous PG versions. For example: PG 7.4 (one day = 24 hours): select now(); now ------------------------------- 2009-03-09 12:05:42.533139-07 select now()-'2 days'::interval; ?column? ------------------------------- 2009-03-07 11:05:43.963526-08 But in 8.3 (day interval is DST aware): select now(); now ------------------------------- 2009-03-09 12:04:21.813654-07 select now()-'2 days'::interval; ?column? ------------------------------- 2009-03-07 12:04:47.693384-08 That's just in the database itself and without cross-country processing (i.e.: if you have somewhat synchronized processes that assume that New York is 3 hours ahead of San Francisco you can have problems if you don't consider that New York changed to DST 3 hours ahead of San Francisco). Then there are the scripts that calculate dates externally for feeding into your database-backed processes (for fun, try "-d yesterday" and "-d tomorrow" in most versions of the "date" command in the vicinity of DST changes). Cheers, Steve
В списке pgsql-admin по дате отправления: