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: | |
---|---|---|---|
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:
- The UK is currently in BST, and therefore I'd expect 'date' to print UTC + 1 hour
- The GMT time is about 25 seconds behind what I'd expect it to be.
Change History (5)
comment:1 by , 12 years ago
comment:2 by , 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 , 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 , 12 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:5 by , 12 years ago
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
I'm going to close this because it looks like the issues are really in the target packages, not the timezone or glibc packages.
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:
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?