Thomas Lockhart <[EMAIL PROTECTED]> writes:
|> > > I don't think that our code checks explicitly for a "-1" return, since
|> > > the range is checked just before the call, but it would probably be a
|> > > good idea if it did
|> > As I noticd yesterday, glibc's mktime() has in the current snapsho
Thomas Lockhart <[EMAIL PROTECTED]> writes:
|> > This is the bug report against glibc that prompted the change:
|> >
|http://bugs.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=default&pr=2738
|> > |> Ah, but this might explain why I've always seen on my Linux box a 1
|> > |> second
> > date/time storage problem: timestamp parsed incorrectly...
>
> > It looks like a bad parser or defaults for time values. The
> > example code below explains the problem best. I'm not sure why,
> > or where... but it took me about a day to track down (PostgreSQL
> > is never wrong!). If I in
Sean Chittenden wrote:
>>>The FreeBSD folk are absolutely adamant about having mktime() no
>>>compensate for deadzones between DST shifts and they insist that
>>>the application handle this. Someone's off looking at how other
>>>OS'es handle this, but this could be an arduous battle on that
>>
> >The FreeBSD folk are absolutely adamant about having mktime() no
> >compensate for deadzones between DST shifts and they insist that
> >the application handle this. Someone's off looking at how other
> >OS'es handle this, but this could be an arduous battle on that
> >front. <:~)
>
> Personal
Cuttign down the CC: list this time, apologies if I cut too much and
someone misses a copy of this
Sean Chittenden wrote:
>
>The FreeBSD folk are absolutely adamant about having mktime() no
>compensate for deadzones between DST shifts and they insist that the
>application handle this. Some
> Ugh, I'm too tired to file a gdb report:
>
> 1490t = mktime(tmp);
> (gdb)
> 1491fprintf(stderr, "%p\n", t);
> (gdb) print t
> $7 = -1
>
> Good call Tom. ... I'm going to file a PR w/ FreeBSD.
The FreeBSD folk are absolutely adamant about having mktim
> This is the bug report against glibc that prompted the change:
>
>http://bugs.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=default&pr=2738
> |> Ah, but this might explain why I've always seen on my Linux box a 1
> |> second offset returned from mktime() for dates before 1970. Eve
> > I don't think that our code checks explicitly for a "-1" return, since
> > the range is checked just before the call, but it would probably be a
> > good idea if it did
> As I noticd yesterday, glibc's mktime() has in the current snapshot
> been changed to return -1 for dates before the epoch.
Hi,
On Tue, 9 Apr 2002 at 19:43, Thomas Lockhart wrote:
> I don't think that our code checks explicitly for a "-1" return, since
> the range is checked just before the call, but it would probably be a
> good idea if it did
Indeed.
As I noticd yesterday, glibc's mktime() has in the current snap
> > 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 adj
...
> 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 th
> > Ehh... let me hack/check. Looks like 11. ?? In
> > lib/libc/stdtime/localtime.c, WRONG is defined as -1, not 11.
>
> > 1490t = mktime(tmp);
> > (gdb)
> > 1491fprintf(stderr, "%p\n", t); /* GCC optimizes this
> >
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Ehh... let me hack/check. Looks like 11. ?? In
> lib/libc/stdtime/localtime.c, WRONG is defined as -1, not 11.
> 1490t = mktime(tmp);
> (gdb)
> 1491fprintf(stderr, "%p\n", t); /* GCC optimizes this
>
> > 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
>
> Here is the
Sean Chittenden <[EMAIL PROTECTED]> writes:
> 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 con
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:
> 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
Here is the man page on
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.
> > PostgreSQL 7.2 on i386--freebsd4.5, compiled by GCC 2.95.3 This
> > isn't happy making. What OS are you running? Seems like a lower
> > level problem. Do you know if it's a system call making the
> > formatting call?
>
> PostgreSQL uses system calls to get the current time zone if it is
>
> $ uname -a
> FreeBSD ninja1.internal 4.5-STABLE FreeBSD 4.5-STABLE #0: Fri Apr 5 18:08:12 PST
>2002 [EMAIL PROTECTED]:/opt/obj/opt/src/sys/NINJA i386
> $ psql
> # SELECT timestamp '2002-4-7 2:0:0.0';
> timestamptz
>
> 2036-06-02 22:57:08-07
> # SELECT versi
> > date/time storage problem: timestamp parsed incorrectly...
>
> > It looks like a bad parser or defaults for time values. The
> > example code below explains the problem best. I'm not sure why,
> > or where... but it took me about a day to track down (PostgreSQL
> > is never wrong!). If I in
> date/time storage problem: timestamp parsed incorrectly...
> It looks like a bad parser or defaults for time values. The example code below
>explains the problem best. I'm not sure why, or where... but it took me about a day
>to track down (PostgreSQL is never wrong!). If I include a timezo
23 matches
Mail list logo
