RE: daylight savings nov 2 (US)

Jim,

The 3rd party app sends a schedule of events from the iSeries to a UNIX box. The events are stored in UTC time on the UNIX box.
The app has an option to adjust for the time change, worked at V6R1, not working correctly at V7R1.
We had to disable the adjust option, change from N7 to @BLANK.

Algorithm to be used for adjusting PPV event start times
for DST.
Enter one of the following values:
N7 - adjust PPV start times using new 2007 laws
applicable to the United States and most other
North American countries.
NA - adjust PPV start times using laws applicable to
the United States and most other North American
countries. (1986 rules)
EU - adjust PPV start times using laws applicable to
the European Union.
@BLANK - if settop served by the interface is not
subject to DST.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of midrange
Sent: Saturday, November 01, 2014 2:20 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: daylight savings nov 2 (US)

Paul,
What do you mean by "3rd party app that worked at V6R1" - what did or is it supposed to do?

Jim



-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Friday, October 31, 2014 3:01 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: daylight savings nov 2 (US)

Related to time change, is anyone aware of a change/fix IBM may have made in
V7R1 related to time change.
We have a 3rd party app that worked last year at V6R1, but this year at V7R1 was adjusting the time by 1 hour.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Bruce Vining
Sent: Monday, October 27, 2014 4:48 PM
To: Midrange Systems Technical Discussion
Subject: Re: daylight savings nov 2 (US)

Regarding the question "What if the next person doesn't even look for it and just fires up synchronization from the system? It wouldn't be nice if both methods kept adjusting the time back and forth".

Avoiding that situation is what system value QTIMADJ is all about (check the help text).

Regarding the statement "JUST HOW GRADUAL the "gradual" time adjustment is".

As that is an implementation decision subject to change I hope you don't find anything concrete. My recollection of the original adjustment rate though is that it varied based on the amount of time left for adjustment.
That is, off by an hour the adjustments were more frequent/bigger. Off by a second not so frequent/big. But that could easily have changed in the past
15+ years.

Bruce Vining

On Mon, Oct 27, 2014 at 12:29 PM, <rob@xxxxxxxxx> wrote:

Now I get it. I thought you were interested in rolling your own time
change program, not comparing how IBM and NIST sync up.


http://www.ibm.com/developerworks/lotus/library/ls-keeping_time/

I've been trying to find actual IBM articles that really lay out how
this change occurs. Not having much luck.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: John Yeung <gallium.arsenide@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 10/27/2014 12:53 PM
Subject: Re: daylight savings nov 2 (US)
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



On Mon, Oct 27, 2014 at 10:53 AM, <rob@xxxxxxxxx> wrote:

<rob>
One other thing to consider is maintainability. Is someone else
coming along going to be able to maintain your program?
</rob>

<John>
Is this still directed at me? If so, you are still completely
misunderstanding me. If it's directed at someone else, then who?
Did someone else suggest writing a program? If so, I missed it.
</John>

Sorry, my bad I thought the following <snip> Maybe someone should
write a program that goes out and periodically retrieves NIST time
and compares it to system time.
</snip>
involved writing a program.

It does involve writing a program, and I did suggest it. What you
don't seem to be getting at all is that the program is not meant to
synchronize anything. It's not meant to have any effect whatsoever on
the system time. It's not meant to stay on the system any longer than
it takes for me to gather the information that I'm interested in.

The point of the program is to find out, by empirical observation
instead of consulting documentation, JUST HOW GRADUAL the "gradual"
time adjustment is. (I am a big fan of documentation, but it appears
that this is some kind of special, secret sauce that IBM doesn't share
with just anyone, judging by the inability of anyone on this list to
produce a link to specific details.)

So the plan would be...

***IF*** our system does use the gradual time adjustment for Daylight
Saving Time (and this whole exercise is pointless if it doesn't),

***THEN*** have a job that starts several hours before the time change
and ends several hours after the time change, polling NIST every few
moments to see what the difference is between system time and actual
time, and logging the results so that...

...I can inspect them on Monday to see what the system did to effect
this so-called "gradual" change. After that, I can delete the
program, with curiosity satisfied.

Do you really have trouble with the idea that someone could want to
discover information without doing anything "practical" with it? Or
is this an elaborate joke that I've completely missed?

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


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

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

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


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