OT: Daylight savings time, damm programmers

[Martin Riddle]

What is with these programmers these days. Before the y2k fiasco, the
DST changeover was nicely recognized as the first and last sunday of the
month (April/Oct).

I have a few new devices (Linksys routers etc) that I get the only
option to set a Month day and date.
Great, like these idiots didn't realize that in the Julian calendar the
actual dates rarely fall on the same Day.

So now every year I get to set the clocks manually, fantastic.

Where do I apply?

Cheers

 

[D Yuniskis]

What is with these programmers these days. Before the y2k fiasco, the
DST changeover was nicely recognized as the first and last sunday of the
month (April/Oct).

I have a few new devices (Linksys routers etc) that I get the only
option to set a Month day and date.
Great, like these idiots didn't realize that in the Julian calendar the
actual dates rarely fall on the same Day.

So now every year I get to set the clocks manually, fantastic.

Move someplace that *doesn't* observe DST! ;-)

 

[Martin Riddle]

On a sunny day (Sun, 14 Mar 2010 12:27:14 -0400) it happened "Martin
Riddle"


I have a script that telnets to my modified Linksys router and sets
the time from NIST.

Wish I could do that, but its an RV042 and I have a couple of VPNs on
it. It's just an bi-yearly annoyance.
Not enough thought was put into it.

Cheers

 

[Martin Riddle]

Move someplace that *doesn't* observe DST! ;-)

Wouldn’t mind living in AZ. ;D

Cheers

 

[D Yuniskis]

Wish I could do that, but its an RV042 and I have a couple of VPNs on
it. It's just an bi-yearly annoyance.
Not enough thought was put into it.

Hasn't Congress dicked with DST start/end dates "more than
once" in recent memory?

Run a time service and let that do the work for you (don't
their products support NTP?)

 

[D Yuniskis]

Hi Martin,

Wouldn’t mind living in AZ. ;D

Try visiting in late July! :-/

(though many of the places I've lived have that problem! )

 

[[email protected]]

Hi Martin,



Try visiting in late July! :-/

(though many of the places I've lived have that problem! )

Yeah, we have a worse problem (though AGW saved us last year). The humidity
tracks the temperature. This time of year it's great. July and August, not
so much.

 

[D Yuniskis]

It is worse; if you run more than one GUI OS on the same computer,
they ALL change the time - making it wrong no matter what you do.

OS should not *change* the time. Rather, it should change the
*offset* used in displaying/referencing the "current time".

 

[Archimedes' Lever]

OS should not *change* the time. Rather, it should change the
*offset* used in displaying/referencing the "current time".

most start with GMT.

 

[Tim Watts]

Robert Baer <[email protected]>
wibbled on Monday 15 March 2010 17:41

It is worse; if you run more than one GUI OS on the same computer,
they ALL change the time - making it wrong no matter what you do.
That is to say, sometimes you will use only one OS for a while during
which time the change takes place, and then later run the other OS.
So, if one "usually" runs the first most of the time, one would think
"allow only that one to make the change"?
But a situation may come up whereby you need to run the other OS for
a number of daze or so - and guess what? the time is wrong for a fair
amount of daze and you need to do e-mails so you make the correction.
Later, you switch back and BINGO the time is wrong (gets changed).

Only decent answer i found is allow NONE of the OSes to change
date/time - and DIY (if you can remember when to do that as the oliticos
like to change the when).

The usual solution, where the OS permits, is tell it to store the time in
the hardware RTC as UTC time. The OS makes its own DST correction when
loading this. I *think* linux and windows can be made to cooperate on this,
but I might be wrong about windows :<

 

[Grant]

Robert Baer <[email protected]>
wibbled on Monday 15 March 2010 17:41



The usual solution, where the OS permits, is tell it to store the time in
the hardware RTC as UTC time. The OS makes its own DST correction when
loading this. I *think* linux and windows can be made to cooperate on this,
but I might be wrong about windows :<

Easy, windoze wants local time. So a dual boot box is set to local
time in the RTC (Linux is happy with either local or UTC). A Linux
(or unix flavour) only box would be set to UTC with a local offset.

In any case the Linux box still runs on epoch time (UTC) for filestamps
and so on. Stupid windoze stamps files with local time, so may get
confusing when, for example, matching files for same name & datestamp.

Here I tell windoze and linux boxes to sync to the localnet Slackware
based firewall/server, which in turn is ntp sync'd to Internet time.

Grant.

 

[Tim Williams]

Ross Island (or somewhere further south)?
North pole?

Yeah, but those are even worse because observe yearlight savings time! :^)

Tim

 

[Fred Abse]

The approach I prefer (Linux-based) is to leave the hardware clock set to
UTC at all times. It never has to change between standard and DST, since
UTC doesn't do daylight savings time at all.

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.

 

[Fred Abse]

I use...

http://www.robomagic.com/swatch.htm

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.

 

[Grant]

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.

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.

 

[D Yuniskis]

Hi Paul,

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

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

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.

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)

 

[Fred Abse]

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.

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

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

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

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.

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

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

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

 

[[email protected]]

Yeah, but those are even worse because observe yearlight savings time! :^)

It's only halfyearlight savings time.

 

[UltimatePatriot]

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.

 

[[email protected]]

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.