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

Thomas Lockhart <lockhart(at)fourpalms(dot)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(at)suse(dot)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."