Meet the Gang   1   2   3   4   5   6   7   8   9

clock setting

From Bryan Henderson

Answered By Bryan Henderson

By this odd chance, the Gang get to be the querents, and we have a real guru to answer our clock questions at hand. Thanks Bryan! -- Heather

As the maintainer of the main Linux hardware clock managing program, Hwclock, I found the Answer Gang discussion and survey of daylight savings time switches and other hardware clock issues enlightening. I'd like to add some important information.

[John Karns] Thanx for your contribution! I for one really appreciate it.

[Ben] First thing, Bryan - thank you for the info, as well as for the very useful job that you're doing!

[Mike] Yes, Bryan, thanks for taking the time to write that explanation, and for offering to debug distribution-caused problems.

First, let me state that the _only_ sane reason to keep your hardware clock in local time is if you sometimes run Windows on the machine. Windows isn't capable of using a hardware clock in any other format. Unfortunately, local time is Hwclock's default and the default that Red Hat and I believe other major distritbutions ship.

[John K] How about time zones where daylight savings doesn't apply?

Then it's less insane to keep your hardware clock in local time, but still not sane.

[Ben] I certainly appreciate it; I'm sure that a number of our readers do as well. One of your tips in here - the persistence of "UTC" - has already let me figure out why my localtime was "backwards" (i.e., 5 hours earlier instead of later) if I set the hardware clock to UTC. I don't use Windows, but I do travel quite a lot, which means I have to keep changing time zones; do you have any advice or pertinent info for doing this

First of all, of course, keep your hardware clock in UTC format. Whenever you enter a new timezone, do a quick 'ln' command to link /etc/localtime to the descriptor for your new timezone.

[Ben] Ah, so. Actually, I've often thought of writing up a "Mobile Linux" article - a sort of a HOWTO for traveling with Linux - and you've just cleared up one of the last pieces of the puzzle. Tres cool. For those folks who need to bounce around as I do, here's something that'll be useful:

See attached chzone1.bash.txt

This script will present you with a menu of choices for the Eastern, Central, Mountain, and Pacific timezones. Pick one, and you're set.

The /usr/share/zoneinfo/US directory may be more appropriate here.

[Ben] Odd. The entire "tz*" suite (tzselect, tzconfig, etc.) uses the "America" version. <looking at the contents of 'US'> Ah. OK, that seems to make sense - at least you'd be setting the timezone by name ( I'd spent a few minutes hopscotching through "tzselect", back and forth, back and forth, to figure out which cities it used for which zones.) So, here's an updated version of "chzone" - this one actually covers a wider range but keeps the choice list down to the actual zones rather than the (possibly confusing) list of cities:

See attached chzone2.bash.txt

The C library (GNU libc 2) looks at /etc/localtime for the description of the local timezone. That can be a symlink to the relevant timezone descriptor in /usr/share/zoneinfo. (I use US Pacific Standard/Daylight time, so I link to /usr/share/zoneinfo/US/Pacific). If you don't have descriptors for every timezone known to man in /usr/share/zoneinfo (5 MB of them come with glibc -- having them all installed appears to be "normal"), you'll have to install them per your distribution. Sometimes they are in /usr/lib/zoneinfo.

Note that changing timezones doesn't cause any time discontinuity. You aren't changing the clock, only the language your system uses to communicate to humans about what time it is.

[Ben] ... (hopefully, without screwing up "/etc/timeadj") other than setting the TZ to the appropriate value? Are there any non-obvious issues with the clock that I should be aware of when I do this?

You change your hardware clock to UTC by adding the --utc option to any clock-setting 'hwclock' command. You only have to do it once, because your choice gets saved in /etc/adjtime and becomes your default in the future.

The major practical drawback to keeping your hardware clock in local time is that in most locales, local time jumps an hour twice a year. The hardware clock is incapable of implementing that. So you have to explicitly reset the hardware clock twice a year. Windows does that automatically. In Linux, you can do it with a startup script and/or cron job, but I'm not aware of any Linux distribution that does it out of the box. If you're running both Linux and Windows, though, I think both would make the adjustment!

[John K] In my case, the time doesn't change, as I'm near to the equator.

Actually, the time doesn't change for anybody; only the local time representation does.

[John K] OK, but I think you understand what I'm saying - daylight savings time doesn't exist here.

[Mike] Where do you live? Indiana?

Why are there not timezone configurations for those locations, and if they're not, how hard is it to copy one and modify it to disable the DST?

He said it's near the equator, and he didn't say he can't do timezones the normal way (in fact, he probably does). He just pointed out that it isn't as advantageous to him as it is to most the world to keep his hardware clock in UTC format, because one of the advantages of UTC format is that you don't have to reset your hardware clock for DST changes.

[John K] Also, the Linux based distributed network I'm setting up, at this time is all contained within one time zone. Thus, I haven't felt compelled to leave my hw clock set for utc. I did try it once on my personal laptop, (sans the --utc option though - I probably used hwclock to set the time, but can't remember all the details) but didn't like the fact the timestamps on my files (ls) were not in agreement with the time as displayed by the 'date' command

The hardware clock format doesn't affect ls and date displays -- unless there's a bug in the system, of course. I do often see people configure their machines for the wrong time zone and then keep the hardware clock set to the wrong time to compensate. This causes some displays to be correct, but always causes something else to be broken.

[John K] I've never done that or even considered doing it, as I can see where it could really distort parts of the system and create havoc. What I'm trying to say here is that, well let me give an example:

• Local time is 1pm
• I create a file
• I do an ls, which shows the file with a date-stamp that's skewed e.g., 6 hrs from local time.

Thus I constantly have to do mental arithmetic to figure relate these times to my frame of reference, which is local time. It's particularly undesirable when those 6 hrs spans midnight, so the date-stamp shows a different day.

And every once in a while you see a program that chooses to display times in UTC (because it's easy). If you lie to your system about what time it is, you can trick that program into displaying local time! But that breaks other programs. If you then lie about what time zone you're in, those other programs start appearing to work, but still other things break. It usually falls apart as soon as you try to communicate to the rest of the world, for example email timestamps.

[John K] - it tends to make things a little bit confusing. So I changed things back to local time.

I do also run Windows but mostly via VMWare on a Linux host. Do you have any info or input in regards to that scenario?

My main concerns are these:

The distributed net that I'm setting up could eventually span outside of the local time zone. When and if that happens, it might make sense to use utc.

If we're still talking about the hardware clock internal format (UTC vs local time), I don't think the issues change when you expand into multiple time zones. Using local time shouldn't be any worse than with one time zone, since Hwclock does all the work of converting between Unix standard format and hardware clock format.

[John K] I have read about the Unix standard format and more or less know what it is, but don't really understand the big picture here - how all the parts fit together.

But if you mean set the timezone on all the machines to UTC so that displayed times are the same on all systems, that's a separate question.

[John K] But the LANs are a heterogeneous mixture of W9x and Linux clients with a Linux server providing application sharing and Internet gateway services. I wish to use samba for W9x file sharing and login / user profile control, as well as run a batch file to sync the clocks on the w9x clients to the server clock. In short, I want to have all clocks more or less synchronized.

I don't quite follow you here - "displayed times"? .. what about syslogd? My concern is mostly with file date-stamps, and system logs. Lets say I'm examining a system log of a remote system located in a different time zone. I would like to avoid confusion about when specific events may have happened in relation to my local time - and this would be my principal motivation for using UTC. For example, I will have a "master server" which will be doing telephone dialup to remote hosts to exchange mail, collect system logs, etc. I would like to have the master server log timestamps of the dialup session agree with those of the remote system logs, rather than all be skewed one or two hours. Same with file creation & modification timestamps. I will likely have a Perl or bash script run via cron on remote systems to collect all files of interest having a date-stamp falling within a certain time period.

My understanding prior to the test I did at least a year ago when I set my hw clock to UTC, was that such date-stamps would be shown (e.g., via ls) as local time, but UTC would allow for a standard that would put all systems using it on an equal level, and would help to eliminate confusion regarding date-stamps on files between different systems. But that didn't seem to be the case - it simply added more confusion.

The usual way to do that is with an ntp network (run ntpd on all the systems. Have a master ntp time server that gets time from some higher authority and distributes it down to everyone else). Don't use Hwclock at all (I mean it -- if you set the hardware clock manually even once, the system won't maintain it automatically after that).

[John K] That's what I have been thinking - sync the "master server" clock via NTP (ADSL has just recently been introduced here, so now a full time Internet connection is possible); then use a system util such as ntpdate or rdate (samba logon batch files for the other OS) to sync all other clocks to the master. Since my "WAN" will be mostly dialup, using the NTP daemon an all servers is not possible or practical.

I still have questions about UTC re: W9x and other flavors under VMWare. I guess a little experimentation is in order.

I hope that I haven't rambled too much, and thanx for your input.

Any thoughts you might care to express about this would be greatly appreciated.

Regardless of in what format you keep your hardware clock, the display of the time by 'date', 'ls', etc. is controlled by the time zone settings as defined by the C library (e.g. the "localtime" function). Remember, the time does not change each Spring and Fall -- only what we call the time changes. Properly configured, the C library routines generate daylight savings time in Summer and standard time in Winter. The underlying clock is oblivious.

[Ben] Is the above configuration anything that needs to be done by the local admin/user, or does the above mean "properly configured by the author/maintainer/etc of the C library"?

It's C library installation options, like the /etc/localtime setup mentioned above.

[Ben] Hm. All I can do is hope - now that my hardware clock presumably resembles something normal - that the Debian installation options are right. Heck, I'll even go so far as to disable my "spring forward, fall back" cron jobs. I'm a brave soul, I am.

The original querent was having trouble with Ls displaying times in UTC instead of local time in Red Hat 6.1. I've dealt with those messy time zone problems (There was a totally different way of doing time zones before Red Hat 6.0, by the way, and the conversion wasn't perfect) many times, and I'd be happy to debug this problem for anyone who is having it.

[John K] I'm a bit fuzzy on this issue too. What is the expected / intended system behavior in this regard? If I set my clock to UTC, and specify hwclock's --utc parm as you have suggested, then the system should compensate in such a way that the ls command would show timestamps reflected as *local time* - or UTC?

I suppose that the system always stamps the files in accordance with the Unix standard format, and it is up to the various parts of the system (ls, tar, and the like) to do conversions in relation to either UTC or local time. What I interpret you as saying is that there have been instances where these various progs are not in agreement concerning the method with which these conversions are done. Am I Correct? I guess it's time for another try at setting one of my boxes to UTC to find out what.

I think this was what I was experiencing as well (SuSE 6.4).

[Ben] A very cool offer indeed - you can't get much better than that if you're having problems with the above. I'm not, but - Bryan, my job takes me to the Bay area on a fairly regular basis; I'd be more than happy to stand you a beer if you're interested, on behalf of all the folks that need and appreciate your help.

I'd love to.

[Ben] Excellent - I'll be up there, let's see <rummaging> the first week of next month <waving at Jim and Heather>. See you then!

(Hmm, perhaps the "beerware" concept is outdated. If all of us bought beers for all the authors and maintainers, there wouldn't be any more authors or maintainers - not sober ones, anyway. And where would we be then?

Down at the pub, nursing a few sharp ginger beers, or root beers if you like them better, until the Guiness wears off and we're safe to drive home. -- Heather

This page edited and maintained by the Editors of Linux Gazette Copyright © 2001
Published in issue 73 of Linux Gazette December 2001

HTML script maintained by Heather Stern of Starshine Technical Services, https://www.starshine.org/

Meet the Gang   1   2   3   4   5   6   7   8   9