As most of you know, Daylight Saving Time ends on this Sunday, October
29th at 2am. Sysadmins should ensure their systems and applications
behave properly. VARs should do a quick check to ensure client
systems don't have problems, and perhaps should be ready on Sunday and
Monday if they do. Transactions which are time-stamped may be subject
to duplication or deletion, and other issues are possible unless code
has already been written to avoid them.

What many people don't know is that DST changes in 2007. Brian Coles
(AIX Engineer/Developer and all around great guy) sent a note around
to colleagues about this yesterday. With permission, I've published
his notes, along with links to other resources on this topic:
http:// removethisNebula-RnD.com/blog/
(Just " removethis" from the address to get to my blog.)

Many systems may not be prepared for when the dates change for DST in
2007. Operating Systems, databases, and business software may require
patches. Tools you may not suspect (like Java and WebSphere) require
patches, and so may the environments they run in. The blog articles
include links to patches for AIX, HP-UX, Solaris, Linux, Java, and
other environments and tools.

Please feel free to send me notes for inclusion in the blog, and to
request information about specific environments.

Regards,
Tony Gravagno
Nebula Research and Development
TG@ removethisNebula-RnD.com

Tony Gravagno wrote:
DST presents a problem for pick-type systems, particularly D3 systems
that maintain their own clock separate from the host system clock.

My concern is about jobs that use the SLEEP command. Most of the
systems that I work on have some sort of "nightly" job that wakes up at
midnight or thereabouts and does a bunch of stuff every night. Since
the host OS (linux in my case) knows about DST and adjusts itself
correctly, I have been tempted to add a little routine that executes
!date and parses the result to determine the system time. I could then
reset the D3 time to match. I could run this every night so that the D3
time and the system time would always be in sync! But wait... since
there are jobs that may be SLEEPing, there are problems. It seems to me
that if the time is adjusted backwards (like this comming sunday) the
SLEEPing jobs will just wait an extra hour (probably ok?) but when the
time is adjusted forward, there is a very real possibility that
SLEEPing jobs will end up waiting an extra 23 hours. And what would
happen to a job that is just SLEEPing for NN seconds?

My solution to this is a SMART.SLEEP program (free to share if anyone
cares) to use in place of the standard SLEEP command. If pausing for NN
seconds, it counts seconds until done. If pausing until a specific
time, it checks to see if the clock has jumped past the target time, if
so then then the SLEEP time is up! (If the time gets adjusted backwards
it does nothing and just wait a little longer.)

Because I never got around to replacing all the SLEEPs in my programs
(and procs) with SMART.SLEEP, this has never been implemented.

Anyone have a better way to handle DST (and adjusting the D3 clock)
without causing problems for SLEEPing jobs?

A similar problem has to do with adjusting the system clock. Solaris
(and probably others) have a way to "drift" the system time, so that
cron jobs, etc will not get confused. But I don't see that in Linux
systems. What does ntpd do if the system time needs to change by a
significant amount? I would think this could cause cron problems too.

Just wondering,

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

On Fri, 27 Oct 2006 05:11:23 -0700, Tony Gravagno
<g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote:

No it doesn't... It starts....


Regards,

Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

If it ain't broke, fix it until it is...

"Bruce Nichol" <reverse_ecurb (AT) taloncs (DOT) com.au> wrote

Hi
Wrong! It started 3 weeks ago. The rest of the world is due to catch up
next year.
I t does show that the D3NT method of using the system clock has some
distinct advantages being updated automatically. Also shows that one should
not use Timedate() as the sole method of ID control. I must admit I made
that mistake in 1982 July and fixed it by September 1982. The latency of
the REALITY CLOCK WAS SIGNIFICANT.
Peter McMurray
"Bruce Nichol" <reverse_ecurb (AT) taloncs (DOT) com.au> wrote

Bruce Nichol wrote:

Hmm. You're right that we are attempting to gain or conserve an extra
hour of daylight, starting in the fall. I see your point but that's
not the concensus so I'll have to disagree.

Daylight Saving Time isn't saving anything, this is really Daylight
Shifting Time, for which there is neither a beginning nor an ending.

People tend to start something in the beginning of the calendar year
and end later in the year. We Spring forward, a nice metaphor for
beginning something. We Fall backward. It's tough to see falling
backward as the beginning of anything good.

When the internet was young I argued that WWW should have been WW,
since Worldwide is one word. I've also argued that BASIC is not
Basic, and that a restaurant named "Stuft Pizza" should serve "stuffed
pizzas", but popular concensus overrules such things and I've decided
to pick my battles more carefully.

We live in a world where institutions of education strive to imbue our
young with teachings of "The Three R's", and only one of those words
actually begins with the letter R. With such logic as prevalent as
this, I've decided to not argue with people who say DST begins in
spring and ends in fall.

Very rarely I find it refreshing to just sit back and enjoy being
wrong. ;^b

Thanks!
T

Pssssst ... TG, some folks are in the Southern Hemisphere <g> ...

Hi Tony
FALL!
That is what a person does when they trip on a ladder. Surely the correct
English language term is Autumn. :-)
Peter McMurray

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

"Tom deL" <ted (AT) blackflute (DOT) com> wrote:
(Copied from my post to the U2 forum where a similar comment was made)

I didn't feel compelled to spell out the fact that DST is changing now
in the USA only, and that some time zones don't shift.

When the USA changes how its clocks are run it does have a global
impact. Systems in other parts of the world may not change at the
same time, but many systems have software that needs to know what time
it is in other parts of the world. Therefore, it seems prudent for
almost everyone to at least check to see what may need to be done. (I
hope I'm being vague enough.)

T

Peter McMurray wrote:
This from a guy who thinks boots and bonnets are parts of a car rather
than articles of clothing?

And besides, "Spring forward, autumn back"? Somehow that doesn't
convey the message.