OT: Daylight savings time, damm programmers

You must have a timezone set, since your post shows as UTC-0700. (Mountain Standard, or Pacific Daylight)

Linux / Unix doesn't use the hardware clock, except when booting , to set the system clock. What matters is the *system* clock. That is usually set to UTC. Files are timestamped in UTC, but *displayed* in whatever the system has been configured to. Hence a file created in Australia will show on a 'nix system in the USA as its US local creation / modification time.

DST doesn't affect the system clock, only the way time is displayed, according to local settings.

If the machine is never shut down, the hardware clock will never be used again. If the system clock is updated (NIST, GPS, etc.), the setting needs to be transferred to the hardware clock either manually or as a cron job.

hwclock --systohc --utc

When that is done, the system updates a file of the hardware clock error, which is later used to compensate for any regular drift in the hardware clock. After a few updates, setting from the hardware clock becomes quite accurate.

It's actually more complicated than I have described, see the clock, hwclock, and adjtimex man pages.

DST is taken care of from whatever timezone file (/etc/localtime) has been installed. There are dozens to choose from, some down to city level, taking care of those pesky States that span time zones and DST.

Time zone information is published on the Web, in man-readable form, which can be compiled (see zic man page) into a library of timezone files when things change, like the recent US DST changes.

I use...

I use ntpdate (free from NIST, probably included in modern Linux distros)

They have a whole suite of utilities for most OSes.

ntpdate 132.163.4.101 from the command line does it.

Doesn't update the hardware clock, only the system clock,so I actually do;

ntpdate 132.163.4.101 ; hwclock --systohc --utc

Runs as a cron job every 12 hours.

In a real time control system, you should *never* jump the clock.

If leap second adjustments (+/- 1 sec) are required in low quality (not understanding that the minute is not always 60 s long, but might be also 59 s long, which has never occurred or 61 s long, which occurs once about every 1-5 years) systems, this should be compensated during several days.

This should include the daylight, leap year and leap second corrections.

Trouble with that approach is it gives a step jump in the machine's notion of time -- which is a Bad Thing if you compile any software.

Better to properly configure your ntp client so the system slews towards the correct time without any nasty jumps.

By all means write the time to hardware if you like, useful if you dual boot into windoze where timekeeping is much less precise. Windoze defaults to an ntpdate-like time update once a week.

Usually you tell a linux machine to call ntpdate on startup, get the time close to ballpark before starting the ntp client.

Grant.

Yes, but this is s.e.d -- not c.realtime! :>

I've taken to *not* offering "wall time" in my API's. I track "system time" which is guaranteed to monotonically increase. Maintaining "syntonicity" (hmmm... not sure that's a real word? how about: "keeping clocks syntonous", instead) is achieved by tweeking the period of the (hardware) jiffy with small enough changes that the jiffy-to-jiffy variation is "practically insignificant" (for sufficiently small values of practically)

Rarely, if ever compile software these days. I'm an analog hardware guy.

No nasty jumps - a few hundredths of a second usually.

Don't use (or even have), Windoze.

Hwclock with correction is good enough, less than a second, now it's conditioned.

It's only halfyearlight savings time.

Arizona, Hawaii.

John

Arizona, except for the Navajo reservation... we have enough daylight already :-) Puerto Rico, Virgin Islands, Guam, and American Samoa also don't observe DST.

Indiana has, in the past, been a mixed mess of time zones. The whole state now observes DST... I think :-) ...Jim Thompson

It is not DST that Indiana has a problem with. They have a problem recognizing the time change at all between the Indiana and Ohio border.

So get yer story straight. The entire state is in the next time zone, regardless of what the dopes that live there think.

They are ALL "Central Time Zone", but many of the "border" counties declare that they are "Eastern Time Zone". I think they do it conveniently around the DST change, and conveniently use Central as well. All so the lazy, dumb idiots can refrain from resetting their clocks and watches.

It is so bad now, that most of the state claims to be Eastern Zone, leaving only 18 Central Zone counties that have half a clue.

he

=A0 =A0...Jim Thompson

e,

I don't know why anyone has to change their clocks. Just go to work an hour earlier in the Spring and an hour later in the Fall.

Of course, if Congress passed a law ordering people to do that, it would be rejected as another symptom of Big Brother Socialism. Better stick with teh clocks.

If you hate DST so, you can go to work an hour later.

, the

y of

ly

dar

ll.

nd

What hate? I find the whole concept humorous.

Simple people do tend to find simple concepts humorous.

And when you arrive at the station to get your train to go to work, you discover that fewer trains actually run in the rush hour, because the timetable hasn't been altered, or you find yourself in a traffic jam because the contraflow system is still set for non-peak hour traffic.

A lot more than just the times for going to work has to change. It's hardly practical. So much simpler to change the clock twice a year, and then forget about it.

Sylvia.

It isn't :(

So if you need to dual-boot, the RTC has to be set to local time. This can be a nuisance if you have an unclean reset (e.g. power failure) and the DST status has changed since the last boot. If you need to dual-boot, rembember to run "hwclock --systohc" whenever the DST status changes (or even via a daily cron job).