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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Lockhart <lockhart(at)fourpalms(dot)org>,pgsql-bugs(at)postgresql(dot)org
Subject: Re: Bug #630: date/time storage problem: timestamp parsed
Date: 2002-04-10 06:13:20
Message-ID: 20020409231320.U66679@ninja1.internal (view raw or flat)
Thread:
Lists: pgsql-bugs
> > Ehh... let me hack/check.  Looks like 11.  ??  In
> > lib/libc/stdtime/localtime.c, WRONG is defined as -1, not 11.
> 
> > 1490                    t = mktime(tmp);
> > (gdb) 
> > 1491                    fprintf(stderr, "%p\n", t);  /* GCC optimizes this
> >                                                         away if I don't do
> > 							something */
> > (gdb) 
> > 0x3c5e5ba0
> > (gdb) print t
> > $1 = 11
> 
> > Doesn't make much sense to me where that'd come from...  ? -sc
> 
> I'd be inclined to believe the 0x3c5e5ba0 (= Mon Feb 04 2002,
> 05:00:00 EST according to my local time code) and not the 11.  I
> think gdb is dropping the ball here; most likely, failing to warn
> you that the register that once held t wasn't preserved over the
> fprintf function call.

Ugh, I'm too tired to file a gdb report:

1490                    t = mktime(tmp);
(gdb) 
1491                    fprintf(stderr, "%p\n", t);
(gdb) print t
$7 = -1

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?

backend> delete from tt;       
blank
         1: ctid        (typeid = 27, len = 6, typmod = -1, byval = f)
        ----
backend> insert into tt values ('2002-4-7 2:0:0.0');
blank
         1: tt  (typeid = 1184, len = 8, typmod = -1, byval = f)
        ----
backend> insert into tt values ('2002-4-7 2:45:0.0');
blank
         1: tt  (typeid = 1184, len = 8, typmod = -1, byval = f)
        ----
backend> insert into tt values ('2002-4-7 1:0:0.0');
blank
         1: tt  (typeid = 1184, len = 8, typmod = -1, byval = f)
        ----
backend> insert into tt values ('2002-4-7 3:0:0.0');
blank
         1: tt  (typeid = 1184, len = 8, typmod = -1, byval = f)
        ----
backend> select * from tt;
blank
         1: tt  (typeid = 1184, len = 8, typmod = -1, byval = f)
        ----
         1: tt = "2002-04-07 03:00:00-07"       (typeid = 1184, len = 8, typmod = -1, byval = f)
        ----
         1: tt = "2002-04-07 03:45:00-07"       (typeid = 1184, len = 8, typmod = -1, byval = f)
        ----
         1: tt = "2002-04-07 01:00:00-08"       (typeid = 1184, len = 8, typmod = -1, byval = f)
        ----
         1: tt = "2002-04-07 03:00:00-07"       (typeid = 1184, len = 8, typmod = -1, byval = f)
        ----

-sc

-- 
Sean Chittenden

In response to

Responses

pgsql-bugs by date

Next:From: Thomas LockhartDate: 2002-04-10 06:35:20
Subject: Re: Bug #630: date/time storage problem: timestamp parsed
Previous:From: Tom LaneDate: 2002-04-10 05:01:42
Subject: Re: Bug #630: date/time storage problem: timestamp parsed

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