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
0
LOCAL
Update
The records in the internal DB seem wrong:
root pts/20 127.0.0.1 Thu Aug 25 13:29 - 13:29 (00:00)
modwork_ pts/17 127.0.0.1 Thu Aug 25 10:38 - 11:37 (00:59)
modwork_ pts/18 127.0.0.1 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
Best Answer
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
See the UTC offsets:
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 calledDE
in /usr/share/zoneinfo, so it defaults to UTC time.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
toLOCAL
in/etc/adjtime
.Now since your
adjtime
already containsLOCAL
, 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. ChangingLOCAL
toUTC
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.