On FreeBSD newsyslog shows the same interesting sort of problem witha
'time' value of @T02 on the day of the leap change, sudden;y it'll balk
saying the format of the line is wrong. Could be related on an outside
area as newsyslog uses mktime and some ISO time format.
Sean Chittenden wrote:
>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
>>
>>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 = {tm_sec = 0, tm_min = 0, tm_hour = 3, tm_mday = 7, tm_mon = 3,
> tm_year = 102, tm_wday = 0, tm_yday = 96, tm_isdst = 1,
> tm_gmtoff = -25200, tm_zone = 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
>
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
