Re: Yet Another Timestamp Question: Time Defaults
От | Jasen Betts |
---|---|
Тема | Re: Yet Another Timestamp Question: Time Defaults |
Дата | |
Msg-id | ke31te$pct$1@gonzo.reversiblemaps.ath.cx обсуждение исходный текст |
Ответ на | Re: Yet Another Timestamp Question: Time Defaults (Gavan Schneider <pg-gts@snkmail.com>) |
Список | pgsql-general |
On 2013-01-21, Steve Crawford <scrawford@pinpointresearch.com> wrote: > > Date/time is not trivial. The portions of the PostgreSQL manual dealing > with those data types bear careful and thoughtful reading and rereading > while you experiment at the same time in a psql terminal till it > "clicks." And while some time issues are universal, treatment varies > from program to program - especially regarding assumptions when the > input is ambiguous. I'm in the US Pacific time zone so without further > qualification, "2012-11-04 0130" could be 0130 PST or 0130 PDT. noveber suggests PST failry stongly. > The "date" program on my Linux desktop assumes daylight time: > date -d '2012-11-04 0130' > Sun Nov 4 01:30:00 PDT 2012 november is the DST changeover? > PostgreSQL assumes standard time: > select '2012-11-04 0130'::timestamptz; > timestamptz > ------------------------ > 2012-11-04 01:30:00-08 > > Naturally this can lead to all sorts of "fun" when multiple technologies > are involved. > > Meanwhile if I'm up at that hour and try to schedule a job for immediate > execution via "at now", the "at" program tells me it is "Cowardly > refusing to schedule a job in the past." So much for even internal > consistency. theres an hour in the night that I've learned to never schedlule cron jobs that must run atleast once or at most once. > But you are, of course, free to use the capability that PostgreSQL gives > you to define pretty much any data-type you want along with your desired > casting rules if you so desire. Just don't expect the built-in > definitions to change. -- ⚂⚃ 100% natural
В списке pgsql-general по дате отправления: