[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#12206: test-parse-datetime regression test failure with glibc-2.16.0

From: Bruce Dubbs
Subject: bug#12206: test-parse-datetime regression test failure with glibc-2.16.0
Date: Fri, 17 Aug 2012 00:30:51 -0500
User-agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120628 Firefox/13.0.1 SeaMonkey/2.10.1

Paul Eggert wrote:
It looks like you're running in a setup where 'date'
observes UTC, as opposed to POSIX where 'date' is
supposed to ignore leap seconds.  This test case
assumes the POSIX behavior.  How can we arrange
for the POSIX behavior for the test?  For example,
if we set TZ='EST5' in the environment, are leap
seconds ignored as POSIX says they should be?  If so,
we can arrange to run the test in that environment.

When we run the test suites, TZ is unset. The date program is from coreutils-8.18. When we run the tests, we can change our procedures to set any TZ needed.

If I run 'date -u', it is offset from the plain 'date' by leap seconds.

$ TZ=EST date;date;date -u
Thu Aug 16 23:56:26 EST 2012
Fri Aug 17 04:56:26 GMT 2012
Fri Aug 17 04:56:51 UTC 2012

In test-parse-datetime, gmt_offset() uses localtime() which the man page says is supposed to observe UTC, but glibc-2.16.0 has made some changes in this area as time zone data now has to be installed independently of the glibc tarball.

test-parse-datetime then compares to parse-datetime() in lib/parse-datetime.c which is apparently generated from lib/parse-datetime.y.

I haven't studied parse-datetime() well enough to understand the details, however now I'm confused. I can't tell if the problem is in coreutils, glibc, our the LFS install procedures.

  -- Bruce

reply via email to

[Prev in Thread] Current Thread [Next in Thread]