GNU bug report logs - #12206
test-parse-datetime regression test failure with glibc-2.16.0

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12206 in the body.
You can then email your comments to 12206 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruce Dubbs <bruce.dubbs <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: test-parse-datetime regression test failure with glibc-2.16.0
Date: Wed, 15 Aug 2012 14:56:16 -0500

The test-parse-datetime fails with glibc-2.16.0  The new glibc uses time 
data from http://www.iana.org/time-zones.  This currently uses a 
leapseconds cumulative value of 24.

The problem shows up in the test-parse-datetime.c file:

time_t ref_time = 1304250918;

gmtoff = gmt_offset (ref_time);

p = "2011-05-01T11:55:18";

expected.tv_sec = ref_time - gmtoff;
expected.tv_nsec = 0;
ASSERT (parse_datetime (&result, p, 0));
ASSERT (expected.tv_sec  == result.tv_sec &&
        expected.tv_nsec == result.tv_nsec);

All the ISO 8601 test differ by leapseconds:

string '2011-05-01T11:55:18' diff -24 0
string '2011-05-01T11:55:18' diff 24 0
string '2011-05-01 11:55:18' diff 24 0
string '2011-05-01T11:55:18Z' diff 24 0
string '2011-05-01 11:55:18Z' diff 24 0
string '2011-05-01T11:55:18-07:00' diff 24 0
string '2011-05-01 11:55:18-07:00' diff 24 0
string '2011-05-01T11:55:18-07' diff 24 0
string '2011-05-01 11:55:18-07' diff 24 0

I'm not sure if this is a coreutils or gnulib problem, but it shows up 
in the coreutils regression test.

  -- Bruce Dubbs
     linuxfromscratch.org

Message #8 received at 12206 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bruce Dubbs <bruce.dubbs <at> gmail.com>
Cc: 12206 <at> debbugs.gnu.org
Subject: Re: bug#12206: test-parse-datetime regression test failure with
	glibc-2.16.0
Date: Thu, 16 Aug 2012 20:19:30 -0700

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.

Message #11 received at 12206 <at> debbugs.gnu.org (full text, mbox):

From: Bruce Dubbs <bruce.dubbs <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12206 <at> debbugs.gnu.org
Subject: Re: bug#12206: test-parse-datetime regression test failure with
	glibc-2.16.0
Date: Fri, 17 Aug 2012 00:30:51 -0500

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

Message #14 received at 12206 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bruce Dubbs <bruce.dubbs <at> gmail.com>
Cc: 12206 <at> debbugs.gnu.org
Subject: Re: bug#12206: test-parse-datetime regression test failure with
	glibc-2.16.0
Date: Fri, 17 Aug 2012 00:10:08 -0700

On 08/16/2012 10:30 PM, Bruce Dubbs wrote:
> When we run the tests, we can change our procedures to set any TZ needed.

Could you please try it with TZ='EST5EDT,M3.2.0,M11.1.0'?
If that works, we can change the test program to use that
TZ value by default.

Message #17 received at 12206 <at> debbugs.gnu.org (full text, mbox):

From: Bruce Dubbs <bruce.dubbs <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12206 <at> debbugs.gnu.org,
	LFS Developers Mailinglist <lfs-dev <at> linuxfromscratch.org>
Subject: Re: bug#12206: test-parse-datetime regression test failure with
	glibc-2.16.0
Date: Fri, 17 Aug 2012 12:46:35 -0500

Paul Eggert wrote:
> On 08/16/2012 10:30 PM, Bruce Dubbs wrote:
>> When we run the tests, we can change our procedures to set any TZ needed.
>
> Could you please try it with TZ='EST5EDT,M3.2.0,M11.1.0'?
> If that works, we can change the test program to use that
> TZ value by default.


I found two issues.

cd gnulib-tests
make check TESTS=test-parse-datetime VERBOSE=yes

fails

rm /etc/localtime  (I have this normally set to GMT for testing)
make check TESTS=test-parse-datetime VERBOSE=yes

passes

restoring /etc/localtime

export TZ='EST5EDT,M3.2.0,M11.1.0'
make check TESTS=test-parse-datetime VERBOSE=yes

passes.

We can work with this, but you may want to adjust test-parse-datetime to 
make it more robust.

Setting TZ to GMT, America/Chicago, or EST5EDT fails
Setting TX to UCT0 passes.

BTW, I've never seen the M parameters in TZ before.  What do they do?

  -- Bruce

Message #22 received at 12206-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bruce Dubbs <bruce.dubbs <at> gmail.com>
Cc: 12206-done <at> debbugs.gnu.org,
	LFS Developers Mailinglist <lfs-dev <at> linuxfromscratch.org>
Subject: Re: bug#12206: test-parse-datetime regression test failure with
	glibc-2.16.0
Date: Fri, 17 Aug 2012 11:15:31 -0700

On 08/17/2012 10:46 AM, Bruce Dubbs wrote:
> I've never seen the M parameters in TZ before.  What do they do?

They specify the time zone rules directly, without consulting
the tz database.  Unlike the tz database, they're specified by
POSIX, so they should be more portable.  Also, POSIX says they
ignore leap seconds so they should not have a leap second glitch.

I suspect you've found a glibc bug in its handling of tm_gmtoff
and/or localtime-vs-gmtime when leap seconds are enabled,
which you're welcome to report.

This code is supposed to be testing parse-datetime, not
for glibc bugs, so I pushed the following patch into gnulib
and am marking this as done.  The fix should be propagated into
coreutils the next time it syncs from gnulib.

test-parse-datetime: avoid glibc leap-second glitch
* tests/test-parse-datetime.c (main): Set TZ to US Eastern time
with the 2012 rules.  Problem reported by Bruce Dubbs in
<http://bugs.gnu.org/12206>.
diff --git a/tests/test-parse-datetime.c b/tests/test-parse-datetime.c
index 1c9fd2d..98ce64b 100644
--- a/tests/test-parse-datetime.c
+++ b/tests/test-parse-datetime.c
@@ -123,6 +123,12 @@ main (int argc _GL_UNUSED, char **argv)

   set_program_name (argv[0]);

+  /* Set the time zone to US Eastern time with the 2012 rules.  This
+     should disable any leap second support.  Otherwise, there will be
+     a problem with glibc on sites that default to leap seconds; see
+     <http://bugs.gnu.org/12206>.  */
+  setenv ("TZ", "EST5EDT,M3.2.0,M11.1.0", 1);
+
   gmtoff = gmt_offset (ref_time);

Message #25 received at 12206 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: 12206 <at> debbugs.gnu.org
Cc: eggert <at> cs.ucla.edu
Subject: Re: bug#12206: test-parse-datetime regression test failure with
	glibc-2.16.0
Date: Fri, 17 Aug 2012 21:15:19 +0200

Paul Eggert wrote:
> On 08/17/2012 10:46 AM, Bruce Dubbs wrote:
>> I've never seen the M parameters in TZ before.  What do they do?
>
> They specify the time zone rules directly, without consulting
> the tz database.  Unlike the tz database, they're specified by
> POSIX, so they should be more portable.  Also, POSIX says they
> ignore leap seconds so they should not have a leap second glitch.
>
> I suspect you've found a glibc bug in its handling of tm_gmtoff
> and/or localtime-vs-gmtime when leap seconds are enabled,
> which you're welcome to report.
>
> This code is supposed to be testing parse-datetime, not
> for glibc bugs, so I pushed the following patch into gnulib
> and am marking this as done.  The fix should be propagated into
> coreutils the next time it syncs from gnulib.
>
> test-parse-datetime: avoid glibc leap-second glitch
> * tests/test-parse-datetime.c (main): Set TZ to US Eastern time
> with the 2012 rules.  Problem reported by Bruce Dubbs in
> <http://bugs.gnu.org/12206>.
> diff --git a/tests/test-parse-datetime.c b/tests/test-parse-datetime.c
> index 1c9fd2d..98ce64b 100644
> --- a/tests/test-parse-datetime.c
> +++ b/tests/test-parse-datetime.c
> @@ -123,6 +123,12 @@ main (int argc _GL_UNUSED, char **argv)
>
>    set_program_name (argv[0]);
>
> +  /* Set the time zone to US Eastern time with the 2012 rules.  This
> +     should disable any leap second support.  Otherwise, there will be
> +     a problem with glibc on sites that default to leap seconds; see
> +     <http://bugs.gnu.org/12206>.  */
> +  setenv ("TZ", "EST5EDT,M3.2.0,M11.1.0", 1);
> +
>    gmtoff = gmt_offset (ref_time);

Thanks for the quick fix, Paul.
This will be fixed in coreutils-8.19, coming soon.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.