On 2013-01-21, Steve Crawford <scrawford@xxxxxxxxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
