Re: Bug #630: date/time storage problem: timestamp parsed
От | Andreas Schwab |
---|---|
Тема | Re: Bug #630: date/time storage problem: timestamp parsed |
Дата | |
Msg-id | je4rii1a43.fsf@sykes.suse.de обсуждение исходный текст |
Ответ на | Re: Bug #630: date/time storage problem: timestamp parsed (Thomas Lockhart <lockhart@fourpalms.org>) |
Список | 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 по дате отправления: