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
