Opened 12 years ago

Closed 12 years ago

#3150 closed defect (worksforme)

Glibc-2.16.0 timestamp/timezone issues

Reported by: Matthew Burgess Owned by: bdubbs@…
Priority: normal Milestone: 7.2
Component: Book Version: SVN
Severity: normal Keywords:
Cc:

Description

Upgrading to Glibc-2.16.0 caused testsuite failures in a number of packages, namely coreutils, e2fsprogs, perl, flex, and patch.

These all relate to time/date problems and the 'patch' failure is particularly illuminating and quick/easy to reproduce:

[44] date -u "+%Y-%m-%d %H:%M:%S %z" -r f -- FAILED
--- expected
+++ got
@@ -1 +1 @@
-2009-03-14 00:00:00 +0000
+2009-03-14 00:00:24 +0000

Sure enough, my system is showing a 25 second difference between UTC & GMT; note that the hwclock is stored in UTC and is in sync with public NTP servers:

# echo $LANG
en_GB.UTF-8
# hwclock --utc --show && date -u && date
Mon Aug  6 20:52:29 2012  -0.922193 seconds
Mon Aug  6 20:52:29 UTC 2012
Mon Aug  6 20:52:04 GMT 2012

So, there's 2 things wrong with this:

  1. The UK is currently in BST, and therefore I'd expect 'date' to print UTC + 1 hour
  2. The GMT time is about 25 seconds behind what I'd expect it to be.

Change History (5)

comment:1 by Matthew Burgess, 12 years ago

There's a pre-release of patch-2.6.2 at ftp://alpha.gnu.org/gnu/patch/patch-2.6.1.181-1e6c.tar.gz, the testsuite of which passes.

In addition, trying to run 'tzselect' shows that we need to install the 2 .tab files from the tzdata tarball. Having done that, running tzselect suggested I use "TZ='Europe/London'; export TZ". This is also in accordance with http://www.pixelbeat.org/docs/linux_timezones/index.html. I now get:

# hwclock --show --utc && date -u && date
Mon 06 Aug 2012 22:25:55 BST  -0.703502 seconds
Mon  6 Aug 21:25:55 UTC 2012
Mon  6 Aug 22:25:30 BST 2012

That's a bit better. At least I'm only -25 seconds out now, rather than 1 hour - 25 seconds out. I wonder whether those are leap seconds?

comment:2 by ken@…, 12 years ago

Wikipedia suggests there have been 25 leap seconds so far (table at the side of http://en.wikipedia.org/wiki/Leap_seconds - the green items)

comment:3 by Matthew Burgess, 12 years ago

Thanks Ken, that's also backed up by 'leapseconds' in the tzdata tarball:

# grep -c -E '^Leap' leapseconds
25

So, I think that this now suggests that the bug(s) lie in those packages testsuites rather than with Glibc, especially given that the pre-release of patch appears to have fixed their version of it. It'll take me some time to get used to UTC and GMT differing by such a small amount!

comment:4 by bdubbs@…, 12 years ago

Owner: changed from lfs-book@… to bdubbs@…
Status: newassigned

comment:5 by bdubbs@…, 12 years ago

Resolution: worksforme
Status: assignedclosed

I'm going to close this because it looks like the issues are really in the target packages, not the timezone or glibc packages.

Note: See TracTickets for help on using tickets.