3

I'm having a problem setting the date on my server...

$ ls -la /etc | grep localtime
lrwxrwxrwx  1 root root  23 Mar 6  12:07 /etc/localtime -> /usr/share/zoneinfo/GMT

For some reason, although the time 17:31:06 is GMT, the timezone suffix is EST...

$ date
Tue Mar  6 17:31:06 EST 2012

And the hardware clock is also messed up - 10:32:12 isn't EST:

$ hwclock --show
Tue 06 Mar 2012 10:32:12 PM EST  -0.000276 seconds

If I set the hwclock to the system time or localtime, it sets it incorrectly:

$ hwclock --localtime
Tue 06 Mar 2012 10:34:22 PM EST  -0.000190 seconds
$ date
Tue Mar  6 17:34:24 EST 2012

Any idea what is going on?

Thanks

Tom
  • 691
  • 3
  • 11
  • 23

2 Answers2

6

Three Simple Rules for Not Going Insane When Dealing With Time:

First: You're running Unix (and presumably NTP): Make sure you have set your system's BIOS/Hardware clock to UTC.
The absolute last thing you need is your hardware (BIOS) clock fighting with Unix over whose timezone is right and when daylight saving time begins/ends. Setting your hardware clock to UTC makes life much easier.

Second: When you change the system-wide time zone you sometimes need to log out and log back in again for the system to understand what happened. Generally I suggest rebooting - this ensures every part of the OS has been kicked in the head and understands what has happened.
You don't want cron still running in US/Eastern time when you've changed the machine's timezone to Hawaii.

Third: If you user account still has a messed-up idea of the time zone something is probably setting the TZ environment variable -- double-check your .profile and shell rc files.
Unix doesn't assume that every user on the system is in the local time zone, so it lets you override on a per-user (or per-shell) level. This is very useful if your system is running on (e.g.) US/Eastern time and you have users logging in from Japan - People like the time their system reports to match the clock on their wall :)

voretaq7
  • 79,345
  • 17
  • 128
  • 213
  • 1
    Don't forget `/etc/sysconfig/clock`, too. (Or, will that be updated on reboot from /etc/localtime?) – Aaron Copley Mar 06 '12 at 17:52
  • 1
    ...Because there are so many other worthy things you can go insane over besides dealing with time... – Bart Silverstrim Mar 06 '12 at 17:54
  • 1
    @AaronCopley My systems have no such file (if you use the CentOS tools to change the timezone that should be updated appropriately -- I'm not sure if it's tied to `/etc/localtime`, but if it's not let's add one more non-standard implementation to the litany reasons I despise Linux :) – voretaq7 Mar 06 '12 at 17:59
  • 1
    @voretaq7 Not sure why your hosts don't have it. Very weird! Notice particularly, "ZONE=". http://www.centos.org/docs/5/html/5.1/Deployment_Guide/s2-sysconfig-clock.html It's used by system-config-date so not necessary for actually changing the time, but should probably be of the same value if it exists. – Aaron Copley Mar 06 '12 at 18:16
  • 1
    @AaronCopley Probably because my hosts aren't CentOS (Everything's FreeBSD, with a few Debian/Ubuntu machines laying around that I'm trying to kill, and Debian Don't Do That `/etc/sysconfig` Stuff :) On a redhat box though I would definitely use the `system-config-date` tool to be sure to catch *all* the places the system might be tucking timezone data – voretaq7 Mar 06 '12 at 18:18
  • Followed all your advice and the hwclock and date command still return different times and neither of them are UTC. :( – Tom Mar 09 '12 at 17:55
1

The problem was setting the hwclock to the system time and vice versa (which I was fiddling around with) actually modified the timezone files in /usr/share/zoneinfo. I had to copy fresh zoneinfo files from another server.

So all I can say is DON'T play with setting the system clock to the hardware clock and vice versa (hwclock --hctosys, hwclock --systohc) unless you know what you're doing!

Tom
  • 691
  • 3
  • 11
  • 23