You have have the timezone set incorrect. To see if it works at all use some others (the extremes):
$ TZ=Pacific/Midway date
Mon Sep 28 20:42:02 SST 2015
$ TZ=Pacific/Kiritimati date
Tue Sep 29 21:42:48 LINT 2015
and if you double check your entry against the list you can see you're missing an underscore in the value of $TZ
.
So try
$ TZ=America/Los_Angeles date
and see if your problem persists.
I haven't found any policy for the naming of the timezones, but spaces are never in them and replaced by underscore, but sometimes with a dash. It is probably best to look it up and copy/paste the value, something you, or your source didn't.
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
1472116320
$ TZ=Europe/Berlin date -d 'Thu Aug 25 11:12' +%s
1472116320
See the UTC offsets:
$ TZ=Europe/Berlin date +%z
+0200
$ TZ=US/Pacific date +%z
-0700
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
+0000
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.
Best Answer
timedatectl
updates/etc/localtime
, which is the documented way of setting the default timezone in most Linux-based environments (along with its override, theTZ
environment variable, which is the only POSIX-defined way of specifying the timezone)./etc/timezone
appears to be mostly Debian-specific (including derivatives). On Debian systems,timedatectl set-timezone
also updates/etc/timezone
.If you manually update
/etc/timezone
, you should also update the/etc/localtime
symlink (and make sure you keep the latter a symlink). Updates to/etc/localtime
appear to be taken into account by (most?) desktop environments, so there’s no need to use environment-specific tools to update the timezone.If you’re running Debian, you should use
dpkg-reconfigure tzdata
to configure the default timezone; that updates/etc/localtime
and/etc/timezone
as above, and it also updates the selected timezone in the debconf database (which serves as the default when configuringtzdata
). If you don’t do this, the next timetzdata
is updated, the timezone will be restored to the value in the debconf database.dpkg-reconfigure tzdata
also takes care of updating the SE Linux context, if you’re using SE Linux.