Skip site navigation (1) Skip section navigation (2)

Re: Bug #630: date/time storage problem: timestamp parsed

From: Sean Chittenden <sean(at)chittenden(dot)org>
To: Michael Loftis <mloftis(at)wgops(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Bug #630: date/time storage problem: timestamp parsed
Date: 2002-04-15 07:32:58
Message-ID: 20020415003258.C67242@ninja1.internal (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
> >The FreeBSD folk are absolutely adamant about having mktime() no
> >compensate for deadzones between DST shifts and they insist that
> >the application handle this.  Someone's off looking at how other
> >OS'es handle this, but this could be an arduous battle on that
> >front.  <:~)
> Personally I'd like to see FreeBSD do away with this strange
> behaviour.  It cause my grief because certaint hings *MUST* be done
> at 0200 every day in our system, I was forced to do them manually
> recently, shifing several hours of work into daytime which had to be
> paused and bulked into the next days work.  I realise that this is
> getting off track but it just points out that the FreeBSD behaviour
> is IMHO WRONG.  It causes applications to fail in an unexpected and
> odd way.
> I'm not objecting to pg patching for it (no choice at the moment)
> but I hope the pg team 'officially' puts a little pressure on the
> BSD folk to make this behave as expected.

Feel free to read over their arguments (archive may not be 100% up to

> I don't have any compliance docs at the moment, but this strikes me
> as somewhat out of spec personally.

::shrug:: I've gotten enough push back to have an indifferent opinion:
I just want to see PG work w/ some of the bogus data I get every now
and then.  :~)  -sc

Sean Chittenden

In response to


pgsql-bugs by date

Next:From: Michael LoftisDate: 2002-04-15 07:48:09
Subject: Re: Bug #630: date/time storage problem: timestamp parsed
Previous:From: Michael LoftisDate: 2002-04-15 07:28:52
Subject: Re: Bug #630: date/time storage problem: timestamp parsed

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group