4

I have compared this in different systems, but only get this behavior in an embedded system running Arago linux. I use the date command from BusyBox v.1.13.2

I executed this two commands "simultaneously":

[root@host:~] date; date -u Fri Mar 18 12:56:49 CET 2016 Fri Mar 18 11:57:14 UTC 2016

The output of zdump is as expected (+3600 seconds; +1 hour):

/etc/localtime Sun Mar 29 01:00:24 2015 UT = Sun Mar 29 01:59:59 2015 CET isdst=0 gmtoff=3600 /etc/localtime Sun Mar 29 01:00:25 2015 UT = Sun Mar 29 03:00:00 2015 CEST isdst=1 gmtoff=7200 /etc/localtime Sun Oct 25 01:00:24 2015 UT = Sun Oct 25 02:59:59 2015 CEST isdst=1 gmtoff=7200 /etc/localtime Sun Oct 25 01:00:25 2015 UT = Sun Oct 25 02:00:00 2015 CET isdst=0 gmtoff=3600 /etc/localtime Sun Mar 27 01:00:24 2016 UT = Sun Mar 27 01:59:59 2016 CET isdst=0 gmtoff=3600 /etc/localtime Sun Mar 27 01:00:25 2016 UT = Sun Mar 27 03:00:00 2016 CEST isdst=1 gmtoff=7200 /etc/localtime Sun Oct 30 01:00:24 2016 UT = Sun Oct 30 02:59:59 2016 CEST isdst=1 gmtoff=7200 /etc/localtime Sun Oct 30 01:00:25 2016 UT = Sun Oct 30 02:00:00 2016 CET isdst=0 gmtoff=3600 /etc/localtime Sun Mar 26 01:00:24 2017 UT = Sun Mar 26 01:59:59 2017 CET isdst=0 gmtoff=3600 /etc/localtime Sun Mar 26 01:00:25 2017 UT = Sun Mar 26 03:00:00 2017 CEST isdst=1 gmtoff=7200

Where does this offset of 25 seconds comes from?

Improve this question
7
  • Is the date output continuous, i.e. ten seconds later is really ten seconds later or does it jump randomly? Can you repeat the described behaviour? Is a ntp daemon running? Commented Mar 15, 2016 at 18:32
  • No ntp daemon is running and the embedded system has no access to the internet. The date output is continous...you can follow the change of seconds continously. Commented Mar 15, 2016 at 18:36
  • What is the offset if you do date +%s ; date? Commented Mar 15, 2016 at 18:41
  • 1457841291 Sun Mar 13 04:54:26 CET 2016. Offset=25 seconds. Commented Mar 15, 2016 at 18:47
  • 1
    Odd. It maybe worth following an strace of both of the commands. Commented Mar 15, 2016 at 19:08

3 Answers 3

Reset to default
2

25 seconds was the difference between the POSIX-compliant tz zones and the "right" tz zones during the interval 2012-07-01 until 2015-07-01. If the tzdata is that old and if default time zone for the shell running this command is a POSIX CET and the "-u" time zone is a "right" version of UTC then the "right" code will assume that the system clock violated POSIX by actually counting all the leap seconds, so the "right" code will subtract off those 25 seconds as part of converting system clock to civil time.

Improve this answer
1
  • Alas, my description above is backwards, triple checking is always necessary. In the example the CET is 25 s smaller than the UTC, so that means the CET is looking like a "right" zone and the UTC is looking like a POSIX zone. Commented Apr 28, 2016 at 6:45
2

By following the strace of the first command (date):

open("/etc/localtime", O_RDONLY)

It access the timezone file pointed by /etc/localtime which is /usr/share/zoneinfo/europe/Zurich in my case. So everything fine so far.


The strace of the second command (date -u) gave me hints why it wasn't working properly:

open("/usr/share/zoneinfo/UTC0", O_RDONLY)

There wasn't such a file in the zoneinfo directory, so I had to copy UTC to UTC0 and now everything works as expected.


date; date -u Fri Apr 26 09:52:44 CET 2016 Fri Apr 26 07:52:44 UTC 2016
Improve this answer
1
  • I also don't have /usr/share/zoneinfo/UTC0 but for me the date ; date -u combination works correctly in the Europe/Zurich timezone. Commented Apr 26, 2016 at 9:50
0

The difference between 04:05:12 CET and 1457838339 modulo 86400 is the timezone. If you're getting an offset of 27 seconds, that means that there's something wrong in your timezone definition and it ends up specifying an offset of 27 seconds instead of the intended (presumably) 1 hour. Check your timezone setting, starting with the TZ variable. Arago Linux uses Glibc, which has several options to specify timezones but normally uses timezone files from the standard timezone database (so TZ should be CET or better something like Europe/Paris to obey local DST rules and follow historical evolution; or TZ should be unset to use /etc/localtime). You can use zdump -v to obtain the description of a timezone.

Improve this answer
0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.