Tags:
create new tag
, view all tags
This page is intended to help deal with problems related to time and clocks in Linux, problems often relating to the clock being off by x hours, commonly the difference between GMT and their local time. I had written more about this in an email which I haven't looked for today -- part of what I put on this page today came from my home TWiki and the rest is new, based on some of what I remember from that email.

See man hwclock — it seems to have fairly thorough coverage of some of the issues I rant about later in this document.

See AboutThesePages.

Contents

Email Dates and Times (GMT vs. Local)

I once covered this somewhere else (IIRC), but couldn't immediately find it. This topic is a little bit out of the flow (off topic) to the rest of the page.

When dealing with email (including archived email), I find dates and times reported like this:

Date: 2003-03-26 23:41:09

or this:

Date: Thu, 27 Mar 2003 11:41:09 +1200

At least for email, it seems that a time reported without an offset is GMT (aka UTC), and a time reported with an offset is local time.

The offset is the number of hours and minutes that have been added to (or subtracted from, depending on the sign) GMT to get the local time.

To get GMT from local time, invert the sign and add the offset to the local time. Thus:

27 Mar 2003 11:41:09 +1200

local time is

2003-03-26 23:41:09

GMT.

Eastern Daylight savings Time (EDT) has an offset of -0400, which means that to get GMT I add 4 hours to the local time. If I know GMT and want to get EDT, I subtract 4 hours from GMT. In other words, it is later (in the day) in Greenwich (England) than in Bethlehem, Pennsylvania (USA).

Resources

  • Managing Accurate Date and Time HOWTO, Avi Alkalay -- a different perspective than mine, hence I didn't thoroughly absorb. I think my points below are correct, but it sure is hard to read -- need to revise.
  • Date and Time Formats, Submitted to W3C 15 September 1997 -- there are some other links that sound useful, here is the Abstract:
This document defines a profile of ISO 8601, the International Standard for the representation of dates and times. ISO 8601 describes a large number of date/time formats. To reduce the scope for error and the complexity of software, it is useful to restrict the supported formats to a small number. This profile defines a few date/time formats, likely to satisfy most requirements.
  • Daylight Savings and UNIX? -- just found this thread on Slashdot -- probably worth rereading if I ever have to deal with DST and reports, etc., again.
  • Synchronizing Networks with NTP -- Is Your Network Running On Time?; Glenn Graham; 01/02/2003; -- fairly short article, looks useful (not read, just glanced at).
  • (rhk) Support.TimeZone; ; ; — Some words about why TWiki uses GMT only, and, IIRC, links to the next two (good) articles:
  • (rhk) Daylight Saving and MovableType; ; March 28, 2003; — A quote from a comment on that page: "One of the neat things there is that it doesn't make the usual mistaken assumption that timezones are uniform longitudinal slices that are always a whole number of hours apart. Yes, you really do get half-hour differences." ... "They seem though to have forgotten about Nepal (UTC + 5h45m) - don't ask me why ..."
  • (rhk) The Many Dates and Times of Perl; Dave Rolsky; March 13, 2003; —
  • (rhk) About Daylight Saving Time; ; ; — this series of 7 pages covers more about the background of Dayight Saving (no final s) Time than anything else (Benjamin Franklin had a big hand in getting it started in the US, although, IISC (If I Skimmed Correctly), it was advocated in England and other parts of Europe before then. It is really quite a fascinating set of pages.
  • (rhk) [[][]]; ; ; —
  • (rhk) [[][]]; ; ; —

ToDos

I should address (on this page or some other page some other things related to time in Linux, like the various times associated with a file (can't recall them right now, but) things like ctime, utime (??), ...

Hmm, a little anomaly I discovered some time ago — I hoped (assumed?) that one of the times mentioned above was the "original" file creation time, i.e., the first time the file was saved (I thought maybe "ctime" might be it. That is not the case. _ATM, I can't recall want ctime is.

RPMs

Some rpms for rdate and ntpdate:

Computer Time

Keeping accurate time in a computer is complicated by a number of factors that are currently described (poorly) in the Background section, below.

Sometimes, a quick and dirty way to solve most of the problems, at least to a reasonable extent, is to periodically sync your computer clock to a known good clock, see the next heading.

Commands to sync your clock to a remote clock

This is over the Internet -- you need a working connection to the Internet to do this:

rdate -s clock-1.cs.cmu.edu && hwclock --systohc

The URL to cmu is an accurate clock at Carnegie Mellon University, Pittsburgh, Pa., USA. It probably is a reasonable choice for anybody in the Eastern USA. If you live elsewhere you may want to find a clock nearer to your location.

ntpdate is an alternate command (neither one of these was installed by default with my installation of Mandrake 9.0 -- I selected all the major packages (Developer, Graphics Development, ...) except the server stuff. I've been warned to make sure the ntpd daemon is not running else the following command will not work. (The package is ntp or xntp.)

ntpdate -b -s time.esec.com.au && hwclock --systohc

Aside: My suggestion for finding a nearby clock is based on my understanding of how the time synchonization works. IIUC, your computer sends out a request for a time check and measures the time until it gets a response. It then applies the new time plus a correction factor which, is one-half the time it took to get a response to the request. This is based on an assumption that the time to traverse the network in each direction is the same. It probably does some smarter things which I don't list here (because I don't know) -- it presumably must wait until it knows that the remote clock is attentive and ready to respond, (i.e., it may send some sort of wake up signal before sending the actual request for time, or it may repeat the request several times, throw out the first, and average the rest).

Some other clock setting commands

/sbin/hwclock --set --date="10/10/2001 16:45:20" 
/sbin/hwclock --hctosys 

Aside: I need to confirm the correct names for the clocks -- I think "hc" is the battery backed "hardware" clock (separate from the CPU), and "sys" is the internal clock kept by the cpu.

Background

This sidebar may be somewhat irrelevant and probably not fully correct. Someday, (for the sake of an interesting story?) I (or someone else) might try to make it more correct. I left out that sometimes the original external clocks were atomic based (or based on atomic based clocks), and, I never finished this. (I might have done a better job in an email I wrote once which I haven't gone looking for -- it was probably posted to a list and is archived somewhere.)

<digression 1> Some (one?) of the problems with time in Linux is based on an old assumption which may have been correct at the time, but is no longer correct (IMHO) -- the assumption was that the CPU kept better time than any local hardware clock that might be attached to the computer:

A computer can keep time in two ways: by using a clock separate from the CPU, and by "counting timer interrupts" in the CPU. It was originally assumed (and probably correct) that counting timer interrupts was the most appropriate approach for two reasons -- at the time, counting timer interrupts from a crystal controlled oscillator might have been more accurate, and it was helpful to have a clock in which time was always "monotonically increasing" (it never got an indication of a "negative tick" -- e.g., a current time that was less than the previous current time). Nowadays, the separate clock is often more accurate than counting timer interrupts because:

  • the separate clocks are battery backed clocks with (fairly) accurate crystal oscillators
  • depending on what the CPU is doing, it sometimes doesn't count all the timer interrupts, and loses time. (I won't go into the details of this, because I probably can't do it accurately. One example though, is that some programs disable interrupts for various amounts of time for good reasons, but if interrupts are disabled, a timer interrupt can be missed.)

Aside: Just recently (~ 11 Oct 2002) I saw mention of a problem in one of the XFree mailing lists (xpert?) that was attributed to a "negative tick" situation -- somebody's keyboard froze just after a time synch (it took them a while for them to determine that triggered the freeze). IIRC, the keyboard unfroze sometime later. Anyway, I don't know the details, and I don't know if this really was the problem, and if so, I don't know if it is considered inherent in the design of XFree or is considered a bug and will be addressed. (IMHO, it should be considered a bug, but ???

<sub-digression 1a> Because Linux recognizes that the cpu clock can deviate from the precise time due to missing ticks or whatever, compensation methods have been built into Linux. It goes something like this: When Linux gets an accurate time check, it sets the (cpu) clock to the correct time, and it calculates an error factor. Maybe it recognizes that it's lost 2 seconds per hour since the last time check. Then, in an effort to do better, it applies a correction factor of 2 seconds per hour from then on (till the next time sync).

<sub-digression 2> Another source of confusion present in Linux but not in Dos / Windows is the option to run your hardware clock (the battery backed thingie) at either local time or GMT. Linux has ways to correct it in either case, but if you apply the wrong correction to the wrong time, your clocks are really messed up. Running your clock at GMT is useful under some circumstances, and is my preference.

The reason I see it being useful is because it can help you deal with (business) reports in a logical fashion even with time changes to and from daylight savings time.

You have to consider how to handle reports for the shifts that include the changes to/from daylight savings time -- do you offset the times of the reports for half a year by an hour, or do you have two oddball reports during the year -- one for a seven hour shift and one for a nine hour shift? No matter how you handle those reports, it is somehow less confusing to me to use GMT (which is not changed by daylight savings time), and only deal with the change in the GMT offset due to daylight savings time.

(Clearly, it can be handled properly either way, but local time just seems more confusing. Depending on the direction of change, using local time you will have one complete duplicate hour at the change in one direction, and a missing hour at the change in the other direction -- your logic must be prepared to handle the situation.)

Contributors

  • RandyKramer - 11 Mar 2002
  • Derek Jennings, Sridhar Dhanapalan, and Sevatio from the Mandrake newbie mailing list re ntpdate -- 11 Oct 2002
  • <If you edit this page, add your name here, move this to the next line>

Other resources

What URL
home page for NTP http://www.ntp.org
public ntp servers http://www.eecis.udel.edu/~mills/ntp/servers.html
Google/Dmoz list of ntp clients http://directory.google.com/Top/Computers/Software/Internet/Clients/Time/
nisttime - windows client for time, also lists servers http://www.boulder.nist.gov/timefreq/service/its.htm

-- StanleyKnutson - 01 Sep 2003

Page Ratings

Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r13 - 2003-09-01 - StanleyKnutson
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WikiLearn? WebBottomBar">Send feedback
See TWiki's New Look