Re: Fall back STP Adjustments

[Paul Gilmartin]

On Wed, 3 Nov 2021 23:42:33 -0500, Alan Altmark wrote:
>
>Architecturally, the TOD clock follows TAI, with an epoch (TOD = all zeros) of 
>Jan 1, 1900.  It doesn't care about the 37 leap seconds that have been 
>introduced into UTC since the epoch.(hence, TAI)  If you used a standard 
>TOD-to-civil time conversion (which all assume TOD is UTC), the result would 
>be 37 seconds ahead of UTC. If the system is leap second-aware, then it 
>subtracts the leap seconds when generating civil time.  TAI -> UTC -> local 
>time.
> 
I believe there have been 27 leap seconds.  When UTC was established it was
set to coincide with GMT which was then (1972?) 10 seconds behind TAI.
The PoOps describes this pretty well and lists all 27 leap seconds.
Also listed at: .  Note that the
list begins with number 10, not 0.

>When you don't configure leap seconds, the old (and new) algorithms will 
>generate the correct civil time, but the observant person will discern that 
>the epoch has moved 37 seconds backward into December 31, 1899.  (And with 
>each subsequent leap second, it moves backward an additional second.)   
>
I believe the epoch of the TOD is 1900-01-01 00:00:10 (proleptic) TAI (somewhat
mythical because neither TOD nor TAI existed then.)  It's hard to get sign 
conventions
correct.  CVTLDTO is added to TOD; CVTLSO (by IETF convention) subtracted/

--gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Alan Altmark]

On Tue, 2 Nov 2021 15:06:04 +0100, Stefan Skoglund  
wrote:

>my point was that UTC doesnt change one whole hour in a leap.

UTC is not a time zone .  Its value changes only when leap seconds are 
introduced.

>IF two different people in different timezones installs each their own
>z15,  if they push return at exactly the same time. What time
>will the HMC expect the computer to be in ? (sort of.)

The HMC has no expectations about the TOD clock of a CPC.  If you don't have 
the STP feature, a POR will set the TOD clock according to the SE.  If you have 
the STP feature, the SE will set its time to STP time (better clock!).

Architecturally, the TOD clock follows TAI, with an epoch (TOD = all zeros) of 
Jan 1, 1900.  It doesn't care about the 37 leap seconds that have been 
introduced into UTC since the epoch.(hence, TAI)  If you used a standard 
TOD-to-civil time conversion (which all assume TOD is UTC), the result would be 
37 seconds ahead of UTC. If the system is leap second-aware, then it subtracts 
the leap seconds when generating civil time.  TAI -> UTC -> local time.

When you don't configure leap seconds, the old (and new) algorithms will 
generate the correct civil time, but the observant person will discern that the 
epoch has moved 37 seconds backward into December 31, 1899.  (And with each 
subsequent leap second, it moves backward an additional second.)   

Alan Altmark
IBM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Alan Altmark]

On Tue, 2 Nov 2021 11:52:21 -0500, Paul Gilmartin  wrote:

>z/OS shirks the issue by making user address spaces non-dispatchable during a 
>leap second.

I wouldn't say "shirks".  Perhaps "accommodates" might be a better word. 

If you don't configure leap seconds in the timing network defintition (CTN), 
STP thinks Coordinated Server Time (CST) is wrong and begins to steer out the 
1-second difference.  As Tim noted, that takes about 7 hours.  Those with 
strict time stamp requirements can't tolerate it being wrong for 7 hours, so 
suspending the application for one second is preferable.

> z/VM?

Tim pointed to my article.  z/VM will give the wrong time if you have leap 
seconds configured in the CTN.

>I have seen some discussion of inserting leap seconds at 23:59:60 local
>time rather than UTC.  Bad Idea.

The discussion getting more traction in the scientific community is to abandon 
the leap second entirely.

Alan Altmark
IBM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Carmen Vitullo]

:) and that's where my brain starts to hurt, sounds like the engineer that had 
the discussion with me about time, miles above my head, but very interesting. 
he when a bit further talking about space / time and relativity, some big bang 
theory - I shook my head in agreement like I understood, nodded a lot and 
thanked him for the discussion that started about about time spent on a project 
:)  
   
Carmen Vitullo 

   

-Original Message-

From: CM 
To: IBM-MAIN 
Date: Tuesday, 2 November 2021 7:58 PM CDT
Subject: Re: Fall back STP Adjustments

AFAIK The time of the Earth's rotation is not a constant, but is subject 
to the variable position of its inner iron-core relative to the Earth's 
geometric center. The closer this inner iron-core is to the Earth's 
center, the faster too is the Earth's rotation - else, the further it is 
from the Earth's center, the slower too is the Earth's rotation (as per 
the conservation of angular momentum). 
  

On 02/11/2021 19:46, Mike Schwab wrote: 
> And I think adding a second inside a minute is a mistake. Seconds 
> 00-59, Minutes 00-59, Length of day dependends on the planet. An 
> Earth Day is usually 24:00.00 but can vary to 23:59:59 or 24:00:01, 
> used to be about 11 hours 4 Billion years ago. Earth days seem to be 
> longer by 1/3 of a second after 50 years of precise measuring, so 
> estimating a leap second every year after 150 years and 1 second every 
> day in 54,000 years. 
> 
> A Mars day is 24:37:00. People working with various Mars probes 
> arrive 37 minutes later each day since their work arrives from Mars at 
> that time. At least they don't get the jet lag when you have to 
> change shifts by 8 hours over a weekend. 
> 
> On Tue, Nov 2, 2021 at 4:33 PM Alan Altmark  wrote: 
>> On Tue, 2 Nov 2021 07:51:00 -0500, Paul Gilmartin  
>> wrote: 
>> 
>>> On Tue, 2 Nov 2021 11:46:56 +0100, Stefan Skoglund wrote: 
>>>> ... UTC never changes, it increases monotonically ... 
>>>> 
>>> Those two statements contradict each other. And both are 
>>> incorrect. UTC falls back at a leap second. 
>> Nope. There is no fall back for leap seconds. They are *inserted* into the 
>> time stream (Temporal Mechanics 101). When that happens, UTC goes from 
>> 11:59:59 to 11:59:60 to 00:00:00. It doesn't pause, repeat, or go backwards. 
>> How an OS translates that concept into its local clock is left an exercise 
>> to the vendor. 
>> 
>> Alan Altmark 
>> IBM 
>> 
>> -- 
>> For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
> 
> 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 

  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Timothy Sipples]

Paul Gilmartin wrote:
>z/OS shirks the issue by making user address spaces non- dispatchable
>during a leap second.

That's one option, the less commonly chosen one. You would choose this 
option if you need your z/OS environment to have highly accurate time that 
fully reflects the leap second the instant it occurs. You might be in this 
situation if your z/OS environment directly supports a financial trading 
exchange open across UTC leap second insertion, for example. [Maybe. The 
exchange presumably would have to halt trading for one second.(*)] This 
one second "pause the world" behavior is to avoid creating UTC time stamps 
that would be duplicates and/or incomprehensible to practically the 
world's entire catalog of leap second ignorant software, possibly 
including parts of z/OS itself.

The other, more popular option is to steer across the leap second. That's 
a Server Time Protocol option, and it takes about 7 hours to adjust to the 
one second delta.

>z/VM?

Short answer: use the popular option (steer across). Longer and fantastic 
answer: see Alan Altmark's excellent article.

http://www.vm.ibm.com/devpages/altmarka/vmleap.html

(*) This scenario vaguely reminds me of Japanese ATM networks (in 
convenience stores typically) that publicly advertise 12:01 AM to 11:59 PM 
service availability. I think they still do that. For whatever reason(s) 
the network needs a brief scheduled outage across midnight every night, 
and in Japan at least that 60 or 120 second daily planned outage is 
advertised lest anyone panic that their first ATM transaction attempt 
didn't work. It's entirely possible that 1 or 2 minute planned outage is 
no longer technically required, but changing the published SLA might 
be..."difficult." :-)

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[CM Poncelet]

AFAIK The time of the Earth's rotation is not a constant, but is subject
to the variable position of its inner iron-core relative to the Earth's
geometric center. The closer this inner iron-core is to the Earth's
center, the faster too is the Earth's rotation - else, the further it is
from the Earth's center, the slower too is the Earth's rotation (as per
the conservation of angular momentum).
 

On 02/11/2021 19:46, Mike Schwab wrote:
> And I think adding a second inside a minute is a mistake.  Seconds
> 00-59, Minutes 00-59, Length of day dependends on the planet.  An
> Earth Day is usually 24:00.00 but can vary to 23:59:59 or 24:00:01,
> used to be about 11 hours 4 Billion years ago. Earth days seem to be
> longer by 1/3 of a second after 50 years of precise measuring, so
> estimating a leap second every year after 150 years and 1 second every
> day in 54,000 years.
>
> A Mars day is 24:37:00.  People working with various Mars probes
> arrive 37 minutes later each day since their work arrives from Mars at
> that time.  At least they don't get the jet lag when you have to
> change shifts by 8 hours over a weekend.
>
> On Tue, Nov 2, 2021 at 4:33 PM Alan Altmark  wrote:
>> On Tue, 2 Nov 2021 07:51:00 -0500, Paul Gilmartin  
>> wrote:
>>
>>> On Tue, 2 Nov 2021 11:46:56 +0100, Stefan Skoglund wrote:
... UTC never changes, it increases monotonically ...

>>> Those two statements contradict each other.  And both are
>>> incorrect.  UTC falls back at a leap second.
>> Nope.  There is no fall back for leap seconds.  They are *inserted* into the 
>> time stream (Temporal Mechanics 101).  When that happens, UTC goes from 
>> 11:59:59 to 11:59:60 to 00:00:00.  It doesn't pause, repeat, or go 
>> backwards. How an OS translates that concept into its local clock is left an 
>> exercise to the vendor.
>>
>> Alan Altmark
>> IBM
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Mike Schwab]

And I think adding a second inside a minute is a mistake.  Seconds
00-59, Minutes 00-59, Length of day dependends on the planet.  An
Earth Day is usually 24:00.00 but can vary to 23:59:59 or 24:00:01,
used to be about 11 hours 4 Billion years ago. Earth days seem to be
longer by 1/3 of a second after 50 years of precise measuring, so
estimating a leap second every year after 150 years and 1 second every
day in 54,000 years.

A Mars day is 24:37:00.  People working with various Mars probes
arrive 37 minutes later each day since their work arrives from Mars at
that time.  At least they don't get the jet lag when you have to
change shifts by 8 hours over a weekend.

On Tue, Nov 2, 2021 at 4:33 PM Alan Altmark  wrote:
>
> On Tue, 2 Nov 2021 07:51:00 -0500, Paul Gilmartin  
> wrote:
>
> >On Tue, 2 Nov 2021 11:46:56 +0100, Stefan Skoglund wrote:
> >>
> >>... UTC never changes, it increases monotonically ...
> >>
> >Those two statements contradict each other.  And both are
> >incorrect.  UTC falls back at a leap second.
>
> Nope.  There is no fall back for leap seconds.  They are *inserted* into the 
> time stream (Temporal Mechanics 101).  When that happens, UTC goes from 
> 11:59:59 to 11:59:60 to 00:00:00.  It doesn't pause, repeat, or go backwards. 
> How an OS translates that concept into its local clock is left an exercise to 
> the vendor.
>
> Alan Altmark
> IBM
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Paul Gilmartin]

On Tue, 2 Nov 2021 11:33:17 -0500, Alan Altmark wrote:
>>>
>>...  UTC falls back at a leap second.
>
>Nope.  There is no fall back for leap seconds.  They are *inserted* into the 
>time stream (Temporal Mechanics 101).  When that happens, UTC goes from 
>11:59:59 to 11:59:60 to 00:00:00.  It doesn't pause, repeat, or go backwards. 
>How an OS translates that concept into its local clock is left an exercise to 
>the vendor.
> 
I stand corrected.  And my Linux will actually display 23:59:60 if I set
TZ=right/...

z/OS shirks the issue by making user address spaces non- dispatchable
during a leap second.  z/VM?

I have seen some discussion of inserting leap seconds at 23:59:60 local
time rather than UTC.  Bad Idea.

I have entertained the idea of making the Fall DST transition at midnight
so the inserted hour could be represented unambiguously as
24:00:00 to 24:59:59.  No enthusiastic support.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Alan Altmark]

On Tue, 2 Nov 2021 07:51:00 -0500, Paul Gilmartin  wrote:

>On Tue, 2 Nov 2021 11:46:56 +0100, Stefan Skoglund wrote:
>>
>>... UTC never changes, it increases monotonically ...
>>
>Those two statements contradict each other.  And both are
>incorrect.  UTC falls back at a leap second.

Nope.  There is no fall back for leap seconds.  They are *inserted* into the 
time stream (Temporal Mechanics 101).  When that happens, UTC goes from 
11:59:59 to 11:59:60 to 00:00:00.  It doesn't pause, repeat, or go backwards. 
How an OS translates that concept into its local clock is left an exercise to 
the vendor.

Alan Altmark
IBM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Stefan Skoglund]

tis 2021-11-02 klockan 07:51 -0500 skrev Paul Gilmartin:
> On Tue, 2 Nov 2021 11:46:56 +0100, Stefan Skoglund wrote:
> > 
> >    ... UTC never changes, it increases monotonically ...
> > 
> Those two statements contradict each other.  And both are
> incorrect.  UTC falls back at a leap second.
> 
> -- gil
> 
> -
> -
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-
> MAIN

my point was that UTC doesnt change one whole hour in a leap.

Ie in the spring this happends :

UTC   CET   CST
00:59:58  01:59:58   -
00:59:59  01:59:59   -
01:00:00   -03:00:00
01:00:01   -03:00:01

and now this saturday night (early morning 31 Oct) :
00:59:58   -02:59:58
00:59:59   -02:59:59
01:00:00   02:00:00   -
01:00:01   02:00:01   -

'-'  Now we don't use this time zone except in the case of the clock in
 the building belongin to an association i'm a member of (very few
 of us was in that building between 1 jan this year until now in
 september so that clock showed swedish normal time all the summer,
 but now it shows the time everyone here expect a clock to show -
 automagic)

and oh yeah the time magicians (ie astronoms) adjust UTC using a
leap second.

IF two different people in different timezones installs each their own
z15,  if they push return at exactly the same time. What time
will the HMC expect the computer to be in ? (sort of.)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Paul Gilmartin]

On Tue, 2 Nov 2021 11:46:56 +0100, Stefan Skoglund wrote:
>
>... UTC never changes, it increases monotonically ...
>
Those two statements contradict each other.  And both are
incorrect.  UTC falls back at a leap second.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Stefan Skoglund]

mån 2021-11-01 klockan 15:09 -0500 skrev Paul Gilmartin:
> On Mon, 1 Nov 2021 12:19:31 -0700, Retired Mainframer wrote:
> 
> > I think the answer is both.  AT 0700 UTC it will be 0200 CDT. 
> > After an
> > infinitely small interval, it will still be 0700 UTC but will be
> > 0100 CST.  At
> > the time of transition, either CST is correct (or maybe neither
> > are).
> > 
> I'm more comfortable with the opposite convention:
>     06:59:59.999... UTC is 01:59:59.999... CDT
>     07:00:00.000... UTC is 01:00:00.000... CST
> 
> Works better rounding to integral seconds.

but this is bonkers. UTC never changes, it increases monotonically and
it doesn't jump back or forward.

My own timezone is CET so as soon as this weekend we go from CST to
CET, but the time in Greenwich doesnt jump. What society does is
changing the offset between it's employed wall clock time ie between 31
october and in April England uses UTC as local wall clock time and
changes to and fro Western European Summer Time.

Which means that this weekend we had 02:59:59 two times in the same
night (sort of)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Eric D Rossman]

It falls back from 0100am to 1200am in your scenario, never switching days

Sent from HCL Verse


   Gibney, Dave --- [EXTERNAL] Re: Fall back STP Adjustments --- 
From:"Gibney, Dave" 
<03b5261cfd78-dmarc-requ...@listserv.ua.edu>To:ibm-m...@listserv.ua.EDUDate:Mon,
 Nov 1, 2021 3:02 PMSubject:[EXTERNAL] Re: Fall back STP Adjustments
  
  A fallback from 2am to 1am local time would be correct, A fall back to 
yesterday, (1am to 12pm) would not be a good idea on many levels> -Original 
Message-> From: IBM Mainframe Discussion List  
On> Behalf Of Carmen Vitullo> Sent: Monday, November 01, 2021 11:32 AM> To: 
IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: Fall back STP Adjustments> > my time 
variables for USS in etc/profile and cee parms have been a non issue> > new to 
me and my issue is when the STP timer actually falls back, 1am or> 2am based on 
the doc I have with automatic time adjustment being done> @7AM UTC time> > > 
Carmen> > On 11/1/2021 1:24 PM, Paul Gilmartin wrote:> > On Mon, 1 Nov 2021 
12:59:43 -0500, Carmen Vitullo wrote:> >> >> I was mistaken yes 7am UTC> >>> > 
And do you have the correct setting in the various (too many) OMVS> > 
configuration files?  For exampe:> >  526 $ tail -1 
/usr/share/zoneinfo/America/Chicago> >  CST6CDT,M3.2.0,M11.1.0> >> > 
(CST6CDT) should suffice.  If so, OMVS processes should adjust> > 
automatically.  Would that Classic MVS were so clever!> >> > Even 
better: zones__;!!JmPEgBY0HMszNaDT!-qT2O4u-> 
T4WtJM01qe0HGqiE_qx_VtEqz3EeCoCyXgxRcTlVy0-NzHPAyMeYnA$ >> > It's free!  z/OS 
Java uses it.> >> >> >> On 11/1/2021 12:57 PM, Ramsey Hallman wrote:> >>> 
Central Daylight Time is 5 hours BEHIND UTC.  As I write this, it's about> >>> 
13:00 CDT.  That's 18:00 UTC.> >>>> >>> Are you sure about the 7 *PM* time  
7AM UTC would be 2AM CDT.> >>>> >>> On Mon, Nov 1, 2021 at 12:47 PM Carmen 
Vitullo  \wrote:> >>>> >>>> I hate to beat a dead horse as it relates to time 
change, but this year we> >>>> have a new z15 and the new HMC version. we're 
setup currently for> automatic> >>>> adjustment, my question is that's not in 
the doc I have; the time will> >>>> change @7PM UTC time according to the doc, 
so that means 2AM> Central time?> >>>> or 1AM central time> > -- gil> >> > 
--> > For 
IBM-MAIN subscribe / signoff / archive access instructions,> > send email 
tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN> >> --> /I am not 
bound to win, but I am bound to be true. I am not bound to> succeed, but I am 
bound to live by the light that I have. I must stand> with anybody that stands 
right, and stand with him while he is right,> and part with him when he goes 
wrong. *Abraham Lincoln*/> > 
--> For 
IBM-MAIN subscribe / signoff / archive access instructions,> send email to 
lists...@listserv.ua.edu with the message: INFO 
IBM-MAIN--For
 IBM-MAIN subscribe / signoff / archive access instructions,send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Eric D Rossman]

It ticks from 015959 to 01. You get 01-015959 twice, but 02 just 
once

Sent from HCL Verse


   Retired Mainframer --- [EXTERNAL] Re: Fall back STP Adjustments --- 
From:"Retired Mainframer" 
<03a485c129c3-dmarc-requ...@listserv.ua.edu>To:ibm-m...@listserv.ua.EDUDate:Mon,
 Nov 1, 2021 3:21 PMSubject:[EXTERNAL] Re: Fall back STP Adjustments
  
  I think the answer is both.  AT 0700 UTC it will be 0200 CDT.  After an 
infinitely small interval, it will still be 0700 UTC but will be 0100 CST.  At 
the time of transition, either CST is correct (or maybe neither are).

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Monday, November 1, 2021 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fall back STP Adjustments

I hate to beat a dead horse as it relates to time change, but this year we 
have a new z15 and the new HMC version. we're setup currently for automatic 
adjustment, my question is that's not in the doc I have; the time will change 
@7PM UTC time according to the doc, so that means 2AM Central time? or 1AM 
central time
thanks
Carmen (mostly confused)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Paul Gilmartin]

On Mon, 1 Nov 2021 12:19:31 -0700, Retired Mainframer wrote:

>I think the answer is both.  AT 0700 UTC it will be 0200 CDT.  After an
>infinitely small interval, it will still be 0700 UTC but will be 0100 CST.  At
>the time of transition, either CST is correct (or maybe neither are).
>
I'm more comfortable with the opposite convention:
06:59:59.999... UTC is 01:59:59.999... CDT
07:00:00.000... UTC is 01:00:00.000... CST

Works better rounding to integral seconds.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Carmen Vitullo]

my brain hurts, but I see what you are getting at, CDT 7AM UTC is 2AM, 
then at CST 7AM UTC is 1AM


I've had many discussion with service engineers about time, and what's 
relative, it made my head spin :)


- Carmen

On 11/1/2021 2:19 PM, Retired Mainframer wrote:

I think the answer is both.  AT 0700 UTC it will be 0200 CDT.  After an
infinitely small interval, it will still be 0700 UTC but will be 0100 CST.  At
the time of transition, either CST is correct (or maybe neither are).

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Carmen Vitullo
Sent: Monday, November 1, 2021 10:47 AM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: Fall back STP Adjustments

I hate to beat a dead horse as it relates to time change, but this year we
have a new z15 and the new HMC version. we're setup currently for automatic
adjustment, my question is that's not in the doc I have; the time will change
@7PM UTC time according to the doc, so that means 2AM Central time? or 1AM
central time
thanks
Carmen (mostly confused)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN


--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Gibney, Dave]

Not wanting to quibble. A one hour fall back from 1am is still, however briefly 
a fallback to yesterday, and is just not a good idea.


> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Retired Mainframer
> Sent: Monday, November 01, 2021 12:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fall back STP Adjustments
> 
> I thought midnight was considered 12AM (if for no other reason than to
> avoid
> an PM/AM transition at 12:01).
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of
> Gibney, Dave
> Sent: Monday, November 1, 2021 12:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fall back STP Adjustments
> 
> A fallback from 2am to 1am local time would be correct, A fall back to
> yesterday, (1am to 12pm) would not be a good idea on many levels
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Retired Mainframer]

I think the answer is both.  AT 0700 UTC it will be 0200 CDT.  After an 
infinitely small interval, it will still be 0700 UTC but will be 0100 CST.  At 
the time of transition, either CST is correct (or maybe neither are).

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Monday, November 1, 2021 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fall back STP Adjustments

I hate to beat a dead horse as it relates to time change, but this year we 
have a new z15 and the new HMC version. we're setup currently for automatic 
adjustment, my question is that's not in the doc I have; the time will change 
@7PM UTC time according to the doc, so that means 2AM Central time? or 1AM 
central time
thanks
Carmen (mostly confused)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Carmen Vitullo]

putting it that way makes sense :) and that's how I read the doc, but 
some folks questions let me to do a sanity check.


always best to check, thanks Dave, thanks all

Carmen

On 11/1/2021 2:01 PM, Gibney, Dave wrote:

A fallback from 2am to 1am local time would be correct, A fall back to 
yesterday, (1am to 12pm) would not be a good idea on many levels


-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of Carmen Vitullo
Sent: Monday, November 01, 2021 11:32 AM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fall back STP Adjustments

my time variables for USS in etc/profile and cee parms have been a non issue

new to me and my issue is when the STP timer actually falls back, 1am or
2am based on the doc I have with automatic time adjustment being done
@7AM UTC time


Carmen

On 11/1/2021 1:24 PM, Paul Gilmartin wrote:

On Mon, 1 Nov 2021 12:59:43 -0500, Carmen Vitullo wrote:


I was mistaken yes 7am UTC


And do you have the correct setting in the various (too many) OMVS
configuration files?  For exampe:
  526 $ tail -1 /usr/share/zoneinfo/America/Chicago
  CST6CDT,M3.2.0,M11.1.0

(CST6CDT) should suffice.  If so, OMVS processes should adjust
automatically.  Would that Classic MVS were so clever!

Even better:<https://urldefense.com/v3/__https://www.iana.org/time-

zones__;!!JmPEgBY0HMszNaDT!-qT2O4u-
T4WtJM01qe0HGqiE_qx_VtEqz3EeCoCyXgxRcTlVy0-NzHPAyMeYnA$ >

It's free!  z/OS Java uses it.



On 11/1/2021 12:57 PM, Ramsey Hallman wrote:

Central Daylight Time is 5 hours BEHIND UTC.  As I write this, it's about
13:00 CDT.  That's 18:00 UTC.

Are you sure about the 7 *PM* time  7AM UTC would be 2AM CDT.

On Mon, Nov 1, 2021 at 12:47 PM Carmen Vitullo  \wrote:


I hate to beat a dead horse as it relates to time change, but this year we
have a new z15 and the new HMC version. we're setup currently for

automatic

adjustment, my question is that's not in the doc I have; the time will
change @7PM UTC time according to the doc, so that means 2AM

Central time?

or 1AM central time

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send emailtolists...@listserv.ua.edu   with the message: INFO IBM-MAIN


--
/I am not bound to win, but I am bound to be true. I am not bound to
succeed, but I am bound to live by the light that I have. I must stand
with anybody that stands right, and stand with him while he is right,
and part with him when he goes wrong. *Abraham Lincoln*/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN

--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Gibney, Dave]

A fallback from 2am to 1am local time would be correct, A fall back to 
yesterday, (1am to 12pm) would not be a good idea on many levels

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Carmen Vitullo
> Sent: Monday, November 01, 2021 11:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fall back STP Adjustments
> 
> my time variables for USS in etc/profile and cee parms have been a non issue
> 
> new to me and my issue is when the STP timer actually falls back, 1am or
> 2am based on the doc I have with automatic time adjustment being done
> @7AM UTC time
> 
> 
> Carmen
> 
> On 11/1/2021 1:24 PM, Paul Gilmartin wrote:
> > On Mon, 1 Nov 2021 12:59:43 -0500, Carmen Vitullo wrote:
> >
> >> I was mistaken yes 7am UTC
> >>
> > And do you have the correct setting in the various (too many) OMVS
> > configuration files?  For exampe:
> >  526 $ tail -1 /usr/share/zoneinfo/America/Chicago
> >  CST6CDT,M3.2.0,M11.1.0
> >
> > (CST6CDT) should suffice.  If so, OMVS processes should adjust
> > automatically.  Would that Classic MVS were so clever!
> >
> > Even better:<https://urldefense.com/v3/__https://www.iana.org/time-
> zones__;!!JmPEgBY0HMszNaDT!-qT2O4u-
> T4WtJM01qe0HGqiE_qx_VtEqz3EeCoCyXgxRcTlVy0-NzHPAyMeYnA$ >
> > It's free!  z/OS Java uses it.
> >
> >
> >> On 11/1/2021 12:57 PM, Ramsey Hallman wrote:
> >>> Central Daylight Time is 5 hours BEHIND UTC.  As I write this, it's about
> >>> 13:00 CDT.  That's 18:00 UTC.
> >>>
> >>> Are you sure about the 7 *PM* time  7AM UTC would be 2AM CDT.
> >>>
> >>> On Mon, Nov 1, 2021 at 12:47 PM Carmen Vitullo  \wrote:
> >>>
> >>>> I hate to beat a dead horse as it relates to time change, but this year 
> >>>> we
> >>>> have a new z15 and the new HMC version. we're setup currently for
> automatic
> >>>> adjustment, my question is that's not in the doc I have; the time will
> >>>> change @7PM UTC time according to the doc, so that means 2AM
> Central time?
> >>>> or 1AM central time
> > -- gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN
> >
> --
> /I am not bound to win, but I am bound to be true. I am not bound to
> succeed, but I am bound to live by the light that I have. I must stand
> with anybody that stands right, and stand with him while he is right,
> and part with him when he goes wrong. *Abraham Lincoln*/
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Carmen Vitullo]

my time variables for USS in etc/profile and cee parms have been a non issue

new to me and my issue is when the STP timer actually falls back, 1am or 
2am based on the doc I have with automatic time adjustment being done 
@7AM UTC time



Carmen

On 11/1/2021 1:24 PM, Paul Gilmartin wrote:

On Mon, 1 Nov 2021 12:59:43 -0500, Carmen Vitullo wrote:


I was mistaken yes 7am UTC


And do you have the correct setting in the various (too many) OMVS
configuration files?  For exampe:
 526 $ tail -1 /usr/share/zoneinfo/America/Chicago
 CST6CDT,M3.2.0,M11.1.0

(CST6CDT) should suffice.  If so, OMVS processes should adjust
automatically.  Would that Classic MVS were so clever!

Even better:
It's free!  z/OS Java uses it.



On 11/1/2021 12:57 PM, Ramsey Hallman wrote:

Central Daylight Time is 5 hours BEHIND UTC.  As I write this, it's about
13:00 CDT.  That's 18:00 UTC.

Are you sure about the 7 *PM* time  7AM UTC would be 2AM CDT.

On Mon, Nov 1, 2021 at 12:47 PM Carmen Vitullo  \wrote:


I hate to beat a dead horse as it relates to time change, but this year we
have a new z15 and the new HMC version. we're setup currently for automatic
adjustment, my question is that's not in the doc I have; the time will
change @7PM UTC time according to the doc, so that means 2AM Central time?
or 1AM central time

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN


--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Paul Gilmartin]

On Mon, 1 Nov 2021 12:59:43 -0500, Carmen Vitullo wrote:

>I was mistaken yes 7am UTC
>
And do you have the correct setting in the various (too many) OMVS
configuration files?  For exampe:
526 $ tail -1 /usr/share/zoneinfo/America/Chicago
CST6CDT,M3.2.0,M11.1.0

(CST6CDT) should suffice.  If so, OMVS processes should adjust
automatically.  Would that Classic MVS were so clever!

Even better: 
It's free!  z/OS Java uses it.


>On 11/1/2021 12:57 PM, Ramsey Hallman wrote:
>> Central Daylight Time is 5 hours BEHIND UTC.  As I write this, it's about
>> 13:00 CDT.  That's 18:00 UTC.
>>
>> Are you sure about the 7 *PM* time  7AM UTC would be 2AM CDT.
>>
>> On Mon, Nov 1, 2021 at 12:47 PM Carmen Vitullo  \wrote:
>>
>>> I hate to beat a dead horse as it relates to time change, but this year we
>>> have a new z15 and the new HMC version. we're setup currently for automatic
>>> adjustment, my question is that's not in the doc I have; the time will
>>> change @7PM UTC time according to the doc, so that means 2AM Central time?
>>> or 1AM central time

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Carmen Vitullo]

I was mistaken yes 7am UTC

thanks


On 11/1/2021 12:57 PM, Ramsey Hallman wrote:

Central Daylight Time is 5 hours BEHIND UTC.  As I write this, it's about
13:00 CDT.  That's 18:00 UTC.

Are you sure about the 7 *PM* time  7AM UTC would be 2AM CDT.

Ramsey

On Mon, Nov 1, 2021 at 12:47 PM Carmen Vitullo  wrote:


I hate to beat a dead horse as it relates to time change, but this year we
have a new z15 and the new HMC version. we're setup currently for automatic
adjustment, my question is that's not in the doc I have; the time will
change @7PM UTC time according to the doc, so that means 2AM Central time?
or 1AM central time
thanks
Carmen (mostly confused)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN


--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Ramsey Hallman]

Central Daylight Time is 5 hours BEHIND UTC.  As I write this, it's about
13:00 CDT.  That's 18:00 UTC.

Are you sure about the 7 *PM* time  7AM UTC would be 2AM CDT.

Ramsey

On Mon, Nov 1, 2021 at 12:47 PM Carmen Vitullo  wrote:

> I hate to beat a dead horse as it relates to time change, but this year we
> have a new z15 and the new HMC version. we're setup currently for automatic
> adjustment, my question is that's not in the doc I have; the time will
> change @7PM UTC time according to the doc, so that means 2AM Central time?
> or 1AM central time
> thanks
> Carmen (mostly confused)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Fall back STP Adjustments

[Carmen Vitullo]

I hate to beat a dead horse as it relates to time change, but this year we have 
a new z15 and the new HMC version. we're setup currently for automatic 
adjustment, my question is that's not in the doc I have; the time will change 
@7PM UTC time according to the doc, so that means 2AM Central time? or 1AM 
central time
thanks 
Carmen (mostly confused) 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN