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

Поиск
Список
Период
Сортировка
От Sean Chittenden
Тема Re: Bug #630: date/time storage problem: timestamp parsed
Дата
Msg-id 20020409154239.N66679@ninja1.internal
обсуждение исходный текст
Ответ на Re: Bug #630: date/time storage problem: timestamp parsed  (Sean Chittenden <sean@chittenden.org>)
Ответы Re: Bug #630: date/time storage problem: timestamp parsed  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Sean Chittenden
Дата:
Сообщение: Re: Bug #630: date/time storage problem: timestamp parsed
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Re: Bug #630: date/time storage problem: timestamp parsed