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
