× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



John, in Al's case, he had to roll the system date forward to a future day
(just like we did for Y2K testing), then rolled it back to resume production
work.  This "leap forward, then back" process leaves system logs and audit
journals littered with datetime values....

I agree that DST time adjustment is not an issue any more, due to the new
options.  

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of John Wallroff
Sent: Monday, February 27, 2006 1:37 PM
To: Midrange Systems Technical Discussion
Subject: RE: Small changes are better RE: Daylight savings time


I don't think that's an issue now with the adjust time feature.  You're
not just simply changing the clock time instantly but instead you're
slowing down or speeding up the clock until it's changed the amount you
specify and then it starts to run at the normal speed again.  This way
you don't have to worry about repeating or skipping any actual time on
the clock.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of DeLong, Eric
Sent: Monday, February 27, 2006 1:22 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Small changes are better RE: Daylight savings time

Yeah, that was a common source of grief during all the Y2K QA testing
about
7 years ago.  There were a bazillion posts about this issue back
then....
You may want to explore alternatives to the method you used.  As you can
see, it's very easy to make a mess of the system when your system leaps
forward and backward in time.

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Al Mac
Sent: Monday, February 27, 2006 12:56 PM
To: Midrange Systems Technical Discussion
Subject: Small changes are better RE: Daylight savings time


I usually do the hour change right after a backup.

I recently had a situation where a shipment was made to a customer a
week 
early in error, and the customer agreed to keep the shipment, provided
the 
billing was as if it got shipped when it was supposed to.

I was able to get the system to do this, by several manipulations, 
including advancing the system date to when the shipment should have
been 
made, then having the billing run, so the "corrected" dates into when 
receivables due and general ledger etc. (fortunately inside the same
fiscal 
period), then putting the system date back to what it should be.

The users quite happy ... which is the case any time Al Mac does some 
"magic" to make data come out "right" without people having to do any
real 
work to accomplish the goals.

I would not be surprised if my action violated SOX.

Wow! I had lots of unexpected chaos for the time frame between the two
dates.
* System log corruption
* automatic scheduler took a vacation

>I'm in the Chicago suburbs and we're using QN0600CST: Central Standard
Time.
>
>Note: If you change QTIMZON, be sure to check your system time
>afterwards; if you had the default offset of 00 hours and you change it
>to -06 hours for CST, your clock may suddenly change.  In this event,
>you can follow up with a CHGSYSVAL QHOUR 'nn' where nn is the right
hour 
>and is in single quotes.  So, to be safe I'd advise you make any
changes 
>after hours or when system activity is minimal.
>
>John A. Jones, CISSP
>Americas Information Security Officer
>Jones Lang LaSalle, Inc.
>V: +1-630-455-2787 F: +1-312-601-1782
>john.jones@xxxxxxxxxx
>
>-----Original Message-----
>From: John Wallroff
>Subject: RE: Daylight savings time question. V5R3
>
>So, what is more correct for a simple shop here in the middle of the
>good ol' USA?  The terms I remember being used in dealing with Daylight

>savings time here have to do with what phase you're in.  As in in the 
>winter here we say "Central Standard Time" and in the summer we would
be 
>in "Central Daylight Time".
>
>Going by what you've told me Bruce I'd say that QN0600S would be the
one 
>I'd want to use.  Is this the option most US Central Time Zone shops
use 
>that don't have to worry about people in other time zones using their
>system?
>
>-----Original Message-----
>From: Bruce Vining
>Subject: Re: Daylight savings time question. V5R3
>
>The difference is the name.  Not all countries in the same time zone
>(UTC offset of -6 for instance) may use the same abbreviations and
>names.
>Since these names/abbreviations can show up on panels, reports, etc
it's 
>important to have the name match the expectations of the country where
the 
>system is being used.  This is one of the reasons there are so many
>*TIMZON descriptions supplied with i5/OS.
>
>Bruce Vining
>
>
>"John Wallroff"
>Subject
>Daylight savings time question.  V5R3
>
>Other then the "Daylight Savings Time Name" what exactly is the
>difference between the time zone identifiers
>
>"QN0600S" Central Standard Time (S) - Daylight Saving Time (DST)
>And
>"QN0600CST" Central Standard Time (CST) - Central Daylight Time (CDT)
>
>They both seem to have the automatic daylight savings time "Enable
>Daylight Saving Time" options setup the same.  What am I missing,
what's 
>the difference?
>
>John.
>
>
>
>
>NOTE: This electronic message and attachment(s), if any, contains
>information which is intended solely for the designated recipient(s).
>Unauthorized disclosure, copying, distribution, or other use of the
>contents of this message or attachment(s), in whole or in part, is
>prohibited without the express authorization of the sender of this
>message.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.