RE: Daylight savings time

<<SNIPPIT>>
> 3.    Thinking "out of the box", I will expect that the guys that work
with
> the internal code will take into consideration the issues with time
overlap,
> time calculations,
>        and others issues that might cause problem on the iSeries.

Okay, but there's only so much they can do.   Programs that expect time
to go forwards, never backwards, will have problems if the time changes
during their run.   There's really very little that the "internals" people
can do about that.

IMHO, people should design their programs better.  Especially if they
expect it to run at 2:00.    All they have to do is use GMT times, or
at least check the QUTCOFFSET sysval when reading the clock.  If your
software takes QUTCOFFET into account, there shouldn't be a problem.

But, the nice thing about having a scheduled job, the way FreeBSD does it,
is that you can change it's schedule to not conflict with batch jobs if
you're concerned about it.

The way Windows does it isn't very good.  But that's not unsusual for
Windows.
<<<end snippit>>>

Speaking from my experience, I have to point out the one dangerous thing
with any os changing the system time - you can code to your hearts delight
to
take into account the time shift (in say 2,000-4,000 programs - not going to
happen)
or you can do it manually, which most distribution/manufacturing companies
prefer to
do, since they run 24/7, a time shift is disastrous if they cannot control
it.
As for coding for the GMT, you still have to account then for the offset,
which will
still give you invalid time calc results unless you can control the time
shift.
All the companies I have been at have to coordinate the clock roll over very
carefully
so as to not mess up jobs and interactive users, even with FreeBSD, could
you condition
the time to be say after 3am ONLY IF job A and job B are complete, because
they may run
longer than you expect, and if they do, the next shift starts at 3:30am and
if it gets
that late, you cannot do the time roll (I have hit this before, we ended up
rolling the
time at noon the next day to avoid manufacturing conflicts) - now could you
even dream
up a auto system that could do that; I prefer to set everything myself -
there are
too many companies out there that have far too many old programs to go
through.

In my true humble opinion on this issue - do away with daylight savings
altogether -
it served its purpose 20 years ago, and has outlived its usefulness in
today's world -
thus, problem solved :)   big cheesy smile (all in all, we have to conform
to how
a business runs itself, some can work with this, some cannot - pick your
poison)



_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.