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

From Andreas Schwab
Subject Re: Bug #630: date/time storage problem: timestamp parsed
Date
Msg-id je4rii1a43.fsf@sykes.suse.de
Whole thread Raw
In response to Re: Bug #630: date/time storage problem: timestamp parsed  (Thomas Lockhart <lockhart@fourpalms.org>)
List pgsql-bugs
Thomas Lockhart <lockhart@fourpalms.org> 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 offset returned from mktime() for dates before 1970. Everything
|> > |> is shifted to allow -1 to be a special value I'll bet...
|> > This is a joke, isn't it?
|>
|> Yes and no; the behavior is in localtime(), not mktime() -- sorry for my
|> faulty memory. The case I am handling is in recovering local time given
|> a time_t (in UTC of course). I have independently derived a broken-down
|> time structure, so have both the original structure and the results of
|> localtime() available in my code. Here is the relevant comment snippet:

Do you have a testcase?

Andreas.

--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

pgsql-bugs by date:

Previous
From: Daniel Ferreira Felix
Date:
Subject: ENC: Datatype time PostGreSql 7.2.1
Next
From: "renaud diez"
Date:
Subject: problem with mandrake 8.2