The symlink of /etc/localtime looks like this:

===> ls -l /etc/localtime 
... /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin

I need this information in the environment variable TZ.

This works:

===> TZ=US/Pacific last reboot| head
reboot   system boot  4.4.0-34-generic Thu Aug 25 02:12   still running
reboot   system boot  4.4.0-34-generic Wed Aug 24 02:14   still running

But this does not:

===> TZ=Europe/Berlin last reboot| head
reboot   system boot  4.4.0-34-generic Thu Aug 25 11:12   still running
reboot   system boot  4.4.0-34-generic Wed Aug 24 11:14   still running

But this does (from Wikipedia Timezones)

===> TZ=DE last reboot| head
reboot   system boot  4.4.0-34-generic Thu Aug 25 09:12   still running
reboot   system boot  4.4.0-34-generic Wed Aug 24 09:14   still running

I search a way to set TZ according to the link of /etc/localtime.

This should be automated and work for all time zones.

last --version: util-linux 2.27.1

===> cat /etc/adjtime
0.0 0 0.0


The records in the internal DB seem wrong:

root     pts/20        Thu Aug 25 13:29 - 13:29  (00:00)
modwork_ pts/17        Thu Aug 25 10:38 - 11:37  (00:59)
modwork_ pts/18        Thu Aug 25 10:05 - 10:19  (00:13)
tguettle tty7         :0               Thu Aug 25 09:12    gone - no logout
reboot   system boot  4.4.0-34-generic Thu Aug 25 11:12   still running

US/Pacific Thu Aug 25 02:12 is Europe/Berlin Thu Aug 25 11:12, as Berlin time is 9 hours ahead of US Pacific time

$ TZ=US/Pacific date -d 'Thu Aug 25 02:12' +%s
$ TZ=Europe/Berlin date -d 'Thu Aug 25 11:12' +%s

See the UTC offsets:

$ TZ=Europe/Berlin date +%z
$ TZ=US/Pacific date +%z

So your second example works. It's the third one that doesn't work.

TZ=DE is invalid as a standard (XXX[offset][YYY[dstoffset]]) zone definition as it only has 2 letters, and there's probably no file called DE in /usr/share/zoneinfo, so it defaults to UTC time.

$ TZ=DE date +%z

If you did boot your system at 9:12 Berlin time, that is at 1472109120 unix time, then that would indicate your clock was off by two hours at the time that entry was added in wtmp.

That is one of the first things done by init when the system starts. That's typically before network time synchronisation services (that would correct that clock) are started. Your other correct wtmp entries suggest the clock was fixed by the time the first person logged in.

If your system is multi-boot and one of the other systems is made by Microsoft, note that Microsoft systems have a bug/misfeature in that they set the hardware clock to the local time instead of UTC by default. So, if your Unix-like OS expects the hardware clock to be in UTC, there will be a conflict, when you boot on the Microsoft OS, the OS will try and shift the hardware clock from UTC to local time, and your Unix OS will do the opposite.

According to there, it seems it's no longer possible to fix Microsoft OSes, so you'd need to work around it by telling your Unix OS that the hardware clock is set to local time like on Windows (and make sure all OSes agree on what the local time means) (and make sure you don't shut down or reboot during/across a DST change). On current Debian systems for instance, that's done by changing UTC to LOCAL in /etc/adjtime.

Now since your adjtime already contains LOCAL, that rules out that hypothesis. Other possibilities: you have another system that sets the clock to UTC, or it's a Microsoft system where the local time is set to UTC. Changing LOCAL to UTC would probably fix the problem.

Or more generally, you'd want all the OSes on the system to agree on what the hardware clock be set to.

  • Please use the command "last" for testing. The command "date" works different. – guettli Aug 25 '16 at 9:06
  • @guettli, what I'm saying is that you used the last command in your question and it appears it works correctly. My last command like your last command works OK, and works the same as the date command. It's your assumptions that are wrong Berlin summer time for US/Pacific time 02:12 is 11:12, not 09:12 (which is UTC time). – Stéphane Chazelas Aug 25 '16 at 9:12
  • My machine booted at 09:12 today (localtime, Berlin). I checked my question again. The output of TZ=DE looks correct. I tried TZ=asdfasdf and it works, too. I guess last falls back to localtime, if it can't parse the TZ variable. – guettli Aug 25 '16 at 9:16
  • @guettli, then it's you clock that is wrong (or at least was wrong at the time of the boot). 1472116320 was recorded in wtmp for your boot time, and that is 09:12 UTC or 11:12 Berlin time. – Stéphane Chazelas Aug 25 '16 at 9:18
  • How can it be, that the "internal" clock is wrong, and I see the correct time on my desktop? For me, the user, everything is correct, except the output of the command last. – guettli Aug 25 '16 at 9:22

Your hardware clock is running in local time rather than UTC, so the boot timestamps are stored incorrectly. (This is indicated by the LOCAL entry in /etc/adjtime.) last doesn't adjust for this, so the boot times it displays are shifted by the difference between your timezone and UTC (two hours currently for Berlin). I don't think there's any way of fixing this, short of changing to UTC for your hardware clock!

The remainder of this answer doesn't pertain to your actual problem, but is still relevant when considering TZ and /etc/localtime.

Generally speaking, to use a file-based value in TZ, you should prefix the filename with : (see tzset(3) for details):

TZ=:Europe/Berlin last reboot|head

This will work with any filename usable as a link from /etc/localtime. If necessary TZDIR can be used to override the default location (/usr/share/zoneinfo).

(This is assuming you're running Linux with glibc; : is implementation-dependent as defined by POSIX. On Linux, you can usually get by without : because both forms of TZ are attempted.)

  • I know how to parse the output of readlink with the shell and use sed to transform the symlink to "TZ=:Europe/Berlin". But maybe there is an easier way? – guettli Aug 25 '16 at 9:05
  • Unfortunately TZ=:Europe/Berlin last reboot shows the wrong dates in my system. I added version info to the question. – guettli Aug 25 '16 at 9:12
  • There's no need to process it, you can use full file paths — TZ=:/usr/share/zoneinfo/Europe/Berlin last reboot|head works fine. – Stephen Kitt Aug 25 '16 at 9:12
  • @guettli Are you sure the time is set correctly? I get the impression your clock is set to local time rather than UTC... – Stephen Kitt Aug 25 '16 at 9:15
  • The output of date is correct. The output of last reboot is wrong. That's all I know. How can I check the setting of my clock? Does it make a difference, since the clock on my ubuntu desktop is correct. – guettli Aug 25 '16 at 9:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.