The term GMT has been replaced with UTC (from the French and translated to Coordinated Universal Time) but it is the same thing.

GMT these days refers to a very few countries and here is an noted explanation:

------------------------

Coordinated Universal Time (UTC) is the basis for civil time today. This 24-hour time standard is kept using highly precise atomic clocks combined with the Earth's rotation.


   A Standard, Not a Time Zone

UTC is the time standard commonly used across the world. The world's timing centers have agreed to keep their time scales closely synchronized - or coordinated - therefore the name Coordinated Universal Time.


   Atomic and Solar Time

Two components are used to determine UTC:

 * *International Atomic Time* (TAI)
   <http://www.timeanddate.com/time/international-atomic-time.html>: A
   time scale that combines the output of some 400 highly precise
   atomic clocks worldwide, and provides the exact speed for our clocks
   to tick.
 * *Universal Time* (UT1), also known as astronomical time or solar
   time, refers to the Earth's rotation. It is used to compare the pace
   provided by TAI with the actual length of a day on Earth
   <http://www.timeanddate.com/time/earth-rotation.html>.


   UT Started in 1884

Universal Time (UT) was created at the Washington Meridian Conference in 1884. This is the basis for the 24-hour time zone system we know today.

At the time, Greenwich Mean Time (GMT) was chosen as the world’s time standard. The reference line or starting point, the Prime Meridian, was determined to be the transit circle at the Royal Observatory in Greenwich, London. The transit circle is a part of the telescope's mechanics and it is still cited as the Prime Meridian's original reference.


    From GMT to UTC

In 1960, the International Radio Consultative Committee formalized the concept of UTC, and it was put into practice the year after. The name Coordinated Universal Time was officially adopted in 1967.

Why UTC – not CUT or TUC? <http://www.timeanddate.com/time/utc-abbreviation.html>

UTC was adjusted several times until 1972, when leap seconds <http://www.timeanddate.com/time/leapseconds.html> were introduced to keep UTC in line with the Earth's rotation, which is not entirely even, and less exact than atomic clocks.


   GMT is now a Time Zone

Until 1972, Greenwich Mean Time (also known as Zulu time <http://www.timeanddate.com/time/zones/z>) was the same as Universal Time (UT).

The difference between GMT and UTC <http://www.timeanddate.com/time/gmt-utc-time.html>

Since then, GMT is no longer a time standard. Today, Greenwich Mean Time <http://www.timeanddate.com/time/zones/gmt> is only the name of a time zone that is used by a few countries in Africa and Western Europe, including the UK during winter <http://www.timeanddate.com/time/united-kingdom-bst.html> and all year in Iceland. <http://www.timeanddate.com/worldclock/iceland/reykjavik>

------------------------

Above comes from url - http://www.timeanddate.com/time/aboututc.html


V.


On 27/10/15 15:20, Mike Schwab wrote:
One solution would be for them to create a new LPAR that runs on GMT.
Customers would be requested to move their apps to the new LPAR and
would benefit by non-disruptive DST changes.
Adjust LPARs as the workload balance changes (memory, processors).

On Tue, Oct 27, 2015 at 8:52 AM, Charles Mills <[email protected]> wrote:

Thanks all. Failed to say that we did ask the service bureau why, and were told 
"because of the time change. " You all have given me the knowledge necessary to 
push back for a better answer.
Summarizing, there are three possible reasons:
1. The hardware clock is set to local time and it is necessary to stop for an 
hour to avoid duplicate timestamps.
2. There are one or more applications that use civil time, are difficult to 
restart without an IPL, and have a  potential duplicate or incorrect time 
problem.
3. Neither of the above, but operations management is in the habit of behaving 
as though one or both were true.
With regard to 1, this is less than a best practice, and should be relatively 
easy to correct, as UTC is ahead of their local time and no duplicate times 
eould result.
2 is more difficult. We are all familiar with unmaintainable applications. Further, they 
are a service bureau and for all I know the application belongs to their largest customer 
who has said "deal with it or we will find a service bureau that can."
With regard to 3, what can I say.
Fair enough summary?
CharlesSent from a mobile; please excuse the brevity

-------- Original message --------
From: Vince Coen <[email protected]>
Date: 10/27/2015  5:54 AM  (GMT-08:00)
To: [email protected]
Subject: Re: RE-IPL for the Daylight to Standard time conversion?

Sunday is the *day *that clocks move forwards or back an hour or two.
e.g., 02:00 etc.

Hardly a heavy work load period unless it is a system upgrade day !

On 27/10/15 11:35, Ted MacNEIL wrote:
What's so special about Sunday? I used to work for an international bank. 
Sunday. Was no excuse for an outage!

-
-teD
-
    Original Message
From: Vince Coen
Sent: Tuesday, October 27, 2015 07:11
To: [email protected]
Reply To: IBM Mainframe Discussion List
Subject: Re: RE-IPL for the Daylight to Standard time conversion?

I would have thought that all these issues would have been easy to be
resolved if all sites used UTC time on hardware level with
the adjustment for local set up at the software level then it only
requires simple job step to adjust if there is not one built in to the O/S.

Also and if needed that no job/processes was allowed to run over the
time period of time change where such a process might get upset.

Let face it as clock change occurs for most of us on a Sunday this
should not really be a major problem.

I am somewhat surprised that IBM does not have standard procedures /
processes / Job in place to handle this including checking the hardware
clock against an external source the same that Unix, Linux, Windows does
even if it has to go through a inhouse Intranet server for security.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to