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

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

From: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
To: Sean Chittenden <sean(at)chittenden(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Bug #630: date/time storage problem: timestamp parsed
Date: 2002-04-10 06:35:20
Message-ID: 3CB3DD28.B4FF07C8@fourpalms.org (view raw or flat)
Thread:
Lists: pgsql-bugs
...
> Good call Tom.  ...  I'm going to file a PR w/ FreeBSD.  I know the
> attached patch is something of a hack, but it works.  I'm not totally
> wild about altering the original time object, but I don't know that I
> have a choice in this case.  Does anyone switch timezones and only
> adjust their clocks by anything other than 60min?  I seem to recall
> that happening in a few places, but the patch isn't any worse than
> where we are now. ::shrug:: This look like an okay patch?

Yuck. You are trying the right things, but I'm not sure that we should
allow mktime() to fail for special cases like this. Falling back to GMT
(a potential offset of up to 12 hours from what was intended by the
user) is (perhaps) unacceptably ugly, particularly for recent/current
epochs which would be reasonably expected to behave correctly.

I'm inclined to test for an error return from mktime(), or to test it as
an ASSERT(), and then throw an error, rather than passing along
garbaged-up values.

Comments?

                        - Thomas

In response to

Responses

pgsql-bugs by date

Next:From: Akula Ramanjaneyul ReddyDate: 2002-04-10 06:40:54
Subject: About creating a new DB
Previous:From: Sean ChittendenDate: 2002-04-10 06:13:20
Subject: Re: Bug #630: date/time storage problem: timestamp parsed

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