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

[Bruce Dubbs]

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