Re: Bug #630: date/time storage problem: timestamp parsed - Mailing list pgsql-bugs

From Sean Chittenden
Subject Re: Bug #630: date/time storage problem: timestamp parsed
Date
Msg-id 20020409154239.N66679@ninja1.internal
Whole thread Raw
In response to Re: Bug #630: date/time storage problem: timestamp parsed  (Sean Chittenden <sean@chittenden.org>)
Responses Re: Bug #630: date/time storage problem: timestamp parsed
List pgsql-bugs
Err... brain-o on my part (didn't know what I was looking for until I
put in a date that does exist and followed it through):

> (gdb) b DecodeDateTime
> Breakpoint 1 at 0x811568d: file datetime.c, line 892.
> (gdb) b DetermineLocalTimeZone
> Breakpoint 2 at 0x81161a9: file datetime.c, line 1463.
> (gdb) run foo
>=20
> backend> create table tt ( tt timestamp );
> backend> insert into tt values ('2002-4-7 2:0:0.0');

If I use 3am on the 7th, I get the following:

(gdb) print *tm
$2 =3D {tm_sec =3D 0, tm_min =3D 0, tm_hour =3D 3, tm_mday =3D 7, tm_mon =
=3D 3,
 tm_year =3D 102, tm_wday =3D 0, tm_yday =3D 96, tm_isdst =3D 1,
 tm_gmtoff =3D -25200, tm_zone =3D 0x28420c78 "PDT"}

Looks like it's a "bug" in mktime() on FreeBSD: it doesn't seem to do
so well with invalid times that happen between daylight savings
time...  or is that a postgres thing for not kicking up an error (out
of bounds time)?  Or should 2am PST be converted to 3am?  -sc

--=20
Sean Chittenden

pgsql-bugs by date:

Previous
From: Sean Chittenden
Date:
Subject: Re: Bug #630: date/time storage problem: timestamp parsed
Next
From: Thomas Lockhart
Date:
Subject: Re: Bug #630: date/time storage problem: timestamp parsed