Local Time conversion to/from UTC Time

[Hardee, Chuck]

Does anyone have any algorithms or code for converting Local Time to UTC Time and vice versa taking Daylight Savings Time into account that they would be willing to share?

My preference would be Assembler but COBOL, PL/I, Fortran, Pascal, etc would be acceptable.

Note, implementations using CONVTOD and TODCONV won't work for my needs.

Thanks,
Chuck

Note: Posted to IBM Main and IBM Assembler

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
CCG Information Technology
Thermo Fisher Scientific
300 Industry Drive
Pittsburgh, PA 15275
Direct: 724-517-2633
FAX: 412-490-9230
Chuck....@ThermoFisher.com

[Dougie Lawson]

http://pic.dhe.ibm.com/infocenter/zos/v1r13/topic/com.ibm.zos.r13.ceea300/clcloct.htm
http://pic.dhe.ibm.com/infocenter/zos/v1r13/topic/com.ibm.zos.r13.ceea300/clcgmto.htm#clcgmto

Plus a bunch of other services at
http://pic.dhe.ibm.com/infocenter/zos/v1r13/topic/com.ibm.zos.r13.ceea300/callref.htm#callref

--
http://twitter.com/DougieLawson

[Ed Jaffe]

On 6/27/2014 4:20 PM, Hardee, Chuck wrote:
> Does anyone have any algorithms or code for converting Local Time to UTC Time and vice versa taking Daylight Savings Time into account that they would be willing to share?
>
> My preference would be Assembler but COBOL, PL/I, Fortran, Pascal, etc would be acceptable.
>
> Note, implementations using CONVTOD and TODCONV won't work for my needs.

Assuming z/OS, you simply add or subtract CVTLDTO and CVTLSO to convert
TOD values between local and UTC.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

[Paul Gilmartin]

On 2014-06-27, at 17:32, Ed Jaffe wrote:

> On 6/27/2014 4:20 PM, Hardee, Chuck wrote:
>> Does anyone have any algorithms or code for converting Local Time to UTC Time and vice versa taking Daylight Savings Time into account that they would be willing to share?
>>
>> My preference would be Assembler but COBOL, PL/I, Fortran, Pascal, etc would be acceptable.
>>
>> Note, implementations using CONVTOD and TODCONV won't work for my needs.
>
> Assuming z/OS, you simply add or subtract CVTLDTO and CVTLSO to convert TOD values between local and UTC.
>

His post on IBM-MAIN suggested he would be dealing with log
files which may span a Daylight Saving Time boundary, or several,
and not all recorded in the time zone in which he was processing.

An answer in IBM-MAIN cited:

http://www.iana.org/time-zones

This is somewhat rubbing salt in the wound in that z/OS does not
support that protocol.

-- gil

[Hardee, Chuck]

The functionality you reference I already have in my program, thanks for the thought, though.

The issue is not "what time is it", locally and UTC, the issue is one set of files has historically data in local time and one set of files has historical data in UTC. I need to convert one or the other to the other time base in order to compare and match.

I'm looking for information on how local time to UTC, and vice versa, is affected by a locale's Daylight Savings Time state.

Chuck

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
CCG Information Technology
Thermo Fisher Scientific
300 Industry Drive
Pittsburgh, PA 15275
Direct: 724-517-2633
FAX: 412-490-9230
Chuck....@ThermoFisher.com

[Steve Hobson]

You probably already know this but local time is ambiguous around when the
clocks "go back". That means there is typically a one hour time range each
year within which the local time cannot be converted to UTC without
additional information.


Best regards, Steve Hobson
CICS Strategy, HLASM Development, Master Inventor
Hursley Laboratories, MP 189, Room A4126, UK
Tie: 246894 International: +44 1962 81 6894

Je me presse de rire de tout, de peur d'être obligé d'en pleurer

IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> wrote on
28/06/2014 17:10:36:

> From: "Hardee, Chuck" <chuck....@thermofisher.com>
> To: ASSEMBL...@listserv.uga.edu,
> Date: 28/06/2014 17:10
> Subject: Re: Local Time conversion to/from UTC Time
> Sent by: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu>
>
> The functionality you reference I already have in my program, thanks
> for the thought, though.
>
> The issue is not "what time is it", locally and UTC, the issue is
> one set of files has historically data in local time and one set of
> files has historical data in UTC. I need to convert one or the other
> to the other time base in order to compare and match.
>
> I'm looking for information on how local time to UTC, and vice
> versa, is affected by a locale's Daylight Savings Time state.
>
> Chuck

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[rkue...@tsys.com]

It looks like these are only available from assembler with CEEENTRY to
generate a prolog. Is that correct?

RtP

Efforts and courage are not enough without purpose and direction. - John
F. Kennedy
Fasten your seat belts, it's going to be a bumpy ride. - Bette Davis (as
character Margo Channing) _All About Eve_1950
Our greatest danger in life is in permitting the urgent things to crowd
out the important. - Charles E. Hummel
Quidquid latine dictum sit, altum videtur.

IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
06/27/2014 07:28:50 PM:

> From: Dougie Lawson <dl1...@gmail.com>
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Date: 06/27/2014 07:31 PM
> Subject: Re: Local Time conversion to/from UTC Time

> Sent by: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU>
>
> http://pic.dhe.ibm.com/infocenter/zos/v1r13/topic/
> com.ibm.zos.r13.ceea300/clcloct.htm
> http://pic.dhe.ibm.com/infocenter/zos/v1r13/topic/

> com.ibm.zos.r13.ceea300/clcgmto.htm#clcgmto
>
> Plus a bunch of other services at
> http://pic.dhe.ibm.com/infocenter/zos/v1r13/topic/
> com.ibm.zos.r13.ceea300/callref.htm#callref

-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you

[Paul Gilmartin]

On 2014-06-28, at 11:07, Steve Hobson wrote:

> You probably already know this but local time is ambiguous around when the
> clocks "go back". That means there is typically a one hour time range each
> year within which the local time cannot be converted to UTC without
> additional information.
>

I'd call it a two hour time range.

The "additional information" may be supplied by the time stamps themselves.
If the time stamps appear in chronological order and events are dense enough
that one can rely on one's occurring in each of the two ambiguous hours,
then a decrease between two recorded time stamps implies the the former is
Daylight time; the latter standard.

-- gil

[Hardee, Chuck]

Yes, it's that additional bit of information I am looking for.
How is conversion during that period around the switch handled.

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
CCG Information Technology
Thermo Fisher Scientific
300 Industry Drive
Pittsburgh, PA 15275
Direct: 724-517-2633
FAX: 412-490-9230
Chuck....@ThermoFisher.com


-----Original Message-----

[Robert A. Rosenberg]

At 18:07 +0100 on 06/28/2014, Steve Hobson wrote about Re: Local Time

conversion to/from UTC Time:

>You probably already know this but local time is ambiguous around when the
>clocks "go back". That means there is typically a one hour time range each
>year within which the local time cannot be converted to UTC without
>additional information.

As I mentioned in a prior reply, a 1:xx time stamp occurring after a
2:xx (or an out of order 1:xx one with a large backward jump is a
good hint./indication of the clock roll-back.

[Robert A. Rosenberg]

At 11:54 -0700 on 06/28/2014, Hardee, Chuck wrote about Re: Local

Time conversion to/from UTC Time:

>Yes, it's that additional bit of information I am looking for.
>How is conversion during that period around the switch handled.

When switching from DST to ST there will be no 2:xxAM time stamps.
1:59AM is UTC-X and the next minute is 3AM and UTC-Y (where Y is
X-1). EST for example is UTC-5 while EDT is UTC-4. For ST to DST, you
watch for a repeat of the 1:xx hour with the first occurrence being
ST and the second being DST (and apply the UTC offsets the same as
above).

[Robert A. Rosenberg]

At 09:10 -0700 on 06/28/2014, Hardee, Chuck wrote about Re: Local

Time conversion to/from UTC Time:

>I'm looking for information on how local time to UTC, and vice
>versa, is affected by a locale's Daylight Savings Time state.

Converting UTC to Local time for historical data is no problem so
long as you know the DST switch dates for the locale. Switching from
local to UTC needs the same info but is harder for the FALL switch
date due to the repeat of the 1AM-1:59AM Hour since there are two of
them on switch date. If you have a series of time stamps (or no time
stamps for 1AM-1:59AM) then you just use a 1:xx time stamp occurring
after a much later 1:xx one to mark the switch from ST to DST. For
SPRING there will be no 2:xx so anything from 3AM on is ST.

[Paul Gilmartin]

I believe you have that backwards. In FALL, switch from DST to ST;
in SPRING from ST to DST.

-- gil

[Gary Weinhold]

Doesn't that depend on your hemisphere?

Gary Weinhold
Data Kinetics, Ltd.

[Paul Gilmartin]

On 2014-07-07, at 09:16, Gary Weinhold wrote:

> Doesn't that depend on your hemisphere?
>

No. Being in close communication with several Aussies, it's
evident to me that they switch from ST to DST in the Spring,
and from DST back to ST in the Fall, just as in the Northern
Hemisphere.

-- gil

[Fred.van....@mail.ing.nl]

> Doesn't that depend on your hemisphere?
>
> Gary Weinhold

Yep: Nothern hemisphere: Spring forward, Fall back and the Southern hemisphere the other way around.

It is described in detail on (amongst other places) http://www.timeanddate.com/time/dst/.

Fred!
-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------

[Gary Weinhold]

I believe I stated that in a confusing manner; what I meant was that
their Spring, when they go to DST, would be the same time as Fall in the
northern hemisphere. I assume "Spring forward" would be in
September/October rather than March/April.

Gary

[Fred.van....@mail.ing.nl]

Mine was confusing too, I think, because they do "Spring forward" too but their spring starts in September when we do our "Fall back"...

Sent from my iPhone

[John Gilmore]

Australia in on the "other' side of the International Date Line and in
the Southern Hemisphere. It has three time zones, and daylight/summer
time is observed in some places and not observed in others.

For concreteness, consider the Australian Eastern Standard Time (AEST)
time zone. In it Daylight time (AEDT) begins at 0200 AEST on the
first Sunday in October and ends at 0200 AEST (sic), i.e., 0300 AEDT,
on the first Sunday in April.

John Gilmore, Ashland, MA 01721 - USA

[Robert A. Rosenberg]

At 04:42 -0600 on 07/07/2014, Paul Gilmartin wrote about Re: Local

Time conversion to/from UTC Time:

>On 2014-07-06, at 23:07, Robert A. Rosenberg wrote:
>
>> At 09:10 -0700 on 06/28/2014, Hardee, Chuck wrote about Re: Local
>>Time conversion to/from UTC Time:
>>
>>> I'm looking for information on how local time to UTC, and vice
>>>versa, is affected by a locale's Daylight Savings Time state.
>>
>> Converting UTC to Local time for historical data is no problem so
>>long as you know the DST switch dates for the locale. Switching
>>from local to UTC needs the same info but is harder for the FALL
>>switch date due to the repeat of the 1AM-1:59AM Hour since there
>>are two of them on switch date. If you have a series of time stamps
>>(or no time stamps for 1AM-1:59AM) then you just use a 1:xx time
>>stamp occurring after a much later 1:xx one to mark the switch from
>>ST to DST. For SPRING there will be no 2:xx so anything from 3AM on
>>is ST.
>
>I believe you have that backwards. In FALL, switch from DST to ST;
>in SPRING from ST to DST.
>
>-- gil

OOPS. I might have it backwards but my principle still stands. There
only ambiguous time stamp is the switch day when the 1AM hour can
occur twice. On that day when you see get to 1:59AM and roll back to
1:00AM again (and thus see timestamps in the 1:xxAM hour earlier than
a previous timestamp) you know to adjust the UTC offset. When you
skip the 2:xxAM hour then you know to use the correct offset for 12M
to 1:59AM and to switch to the other offset when you see 3:00AM.

[John Gilmore]

We seem to have been here before, many, indeed too many times.

There are arguments for displaying or printing local times; there may
be arguments for scheduling things manually using local times. In
the United States, alone in the world, there may perhaps be some
justification for providing hoi polloi with am|m|pm, twelve-hour-clock
values in such situations.

There is no intellectually respectable argument for running an
operating system on anything but UTC. When STCKE values and their
derivatives are UTC-based these pseudo-problems, those of missing and
duplicate timestamp values, do not arise.

I am not so great an admirer of Ludwig Wittgenstein as some
professional philosophers whom I respect, but he did make some points
memorably, and among them was that

About things we know not, we ought to be silent.

[Paul Saers]

If you really want to cover all time stamps, then you must also cover the
sporadic insertions of leap seconds just before midnight 1Jan or 1July.
They are documented in the princ of op. The last one was 2012 July 01 and
IERS has yesterday reported that there will not be any leap second
insertion at 2014Dec31/2015Jan01.
/Paul

[John Gilmore]

Paul Saers wrote

<begin insertion>

If you really want to cover all time stamps, then you must also cover
the sporadic insertions of leap seconds just before midnight 1Jan or
1July.

</end insertion>

The z/Architecture TOD clock provides values trhat are analogous to
International Atomic Time, TAI, ones, which are innocent of
leap-second corrections. UTC values do contain these corrections, and
IBM provides facilities for incorporating their then current net
effect in any notional STCKE value (or not).

Time services coordinated by the BIPM chiefly, but not quite
exclusively, provide UTC not TAI values. If you want an RYO facility
for including net leap-second effects, a simple GLB-seeking
binary-search scheme (NOT a match-seeking one) can be used in a table
of STCKE values and leap-second corrections---Search on STCKE value,
extract the corresponding additive correction---can be used to
provide it. Most people most of the time should use one of the
IBM-supplied facilities instead, leaving table maintenance to it.
Care is required because this sequence of corrections in not a
monotone increasing one. (Single corrections can be either positive
(usually) or negative (infrequently but very likely in the near-term
future).

Yesterday I quoted Wittgenstein's apophthegm,

About things we know not, we ought to be silent.

There is a more abrasive variant of the same principle that is due to
one of our own. The late John McCarthy wrote

Do the math or shut up.

[Rob van der Heij]

On 8 July 2014 14:29, John Gilmore <jwgl...@gmail.com> wrote:


> The z/Architecture TOD clock provides values trhat are analogous to
> International Atomic Time, TAI, ones, which are innocent of
> leap-second corrections. UTC values do contain these corrections, and
> IBM provides facilities for incorporating their then current net
> effect in any notional STCKE value (or not).
>

While it's true that the TOD is ticking steady without knowing about leap
seconds, once you use ETR/STP with NTP to keep pace, the TOD produced by
STCK will effectively give UTC which, as you point out, includes those leap
seconds. When a leap second is inserted in UTC, the TOD (like other NTP
linked systems) will slow down during the rest of the night and be on time
in the morning.

Unless you schedule a change of your own deviation of the UTC at the time
the rest of the folks insert that second (and effectively run the TOD on
TAI rather than UTC). Or can z/OS update the LPAR TOD offset to make run
TAI rather than UTC?

It appears the typical non-steered TOD is about 3 ppm slow, so will be off
by 2 seconds after a week. I can't imagine those installations being
concerned about leap seconds.I would be interested to hear about
installations that deliberately wish to run TAI rather than UTC. For sure
there will be such requirements, or IBM would not have added the ability in
the HMC.

Rob

[Paul Gilmartin]

On 2014-07-08, at 08:57, Rob van der Heij wrote:

> On 8 July 2014 14:29, John Gilmore <jwgl...@gmail.com> wrote:
>
>
>> The z/Architecture TOD clock provides values trhat are analogous to
>> International Atomic Time, TAI, ones, which are innocent of
>> leap-second corrections. UTC values do contain these corrections, and
>> IBM provides facilities for incorporating their then current net
>> effect in any notional STCKE value (or not).
>>
>
> While it's true that the TOD is ticking steady without knowing about leap
> seconds, once you use ETR/STP with NTP to keep pace, the TOD produced by
> STCK will effectively give UTC which, as you point out, includes those leap
> seconds. When a leap second is inserted in UTC, the TOD (like other NTP
> linked systems) will slow down during the rest of the night and be on time
> in the morning.
>

No. There are tables in the Principles of Operation which give TOD
values and corresponding UTC values at each leap second until the
date of publication. These tables make it clear that the TOD runs
not on UTC, but on TAI - 10 seconds (i.e. TOD runs at the atomic clock
rate with orgin at 1900-01-01 00:00:10 in proleptic TAI.)

Current UTC is got by subtracting the correction in CVTLSO from the
value returned by STCK. I know of no z/OS supplied facility that
correctly converts historic TOD values to UTC. (It's not clear
whether STCKCONV does this; IBM refuses to provide detailed documentation
of the behavior of STCKCONV, calling it "common knowledge". IMO,
"common knowledge" without even a citation is a shabby alternative
to documentation.)

GNU utilities under Linux or Cygwin using the TZDATA tables do an
excellent job of converting historic TAI timestamps to UTC. For example:

putenv( "TZ=right/Etc/Zulu");
for ( t = 915148820; t<=915148823; t++ ) /* Circa Jan, 1999 leap second 32. */
showTAI( t );

... (essential subroutines omitted for brevity) prints:

Thu Dec 31 23:59:59 1998
Thu Dec 31 23:59:60 1998
Fri Jan 1 00:00:00 1999
Fri Jan 1 00:00:01 1999

I know JWG objects to the designation of the embolistic second as
"23:59:60". Yes, it contradicts the notion of congruence, but what
is a better name for it.

Interestingly, the TZDATA tables show the same 10-second bias as the
TOD, with their origin at 1970-01-01 00:00:10. In fairness, the
GNU/TZDATA documentation is also meager. I inferred much of this by
reverse engineering.

-- gil

[John Gilmore]

My objections to locutions like

Thu Dec 31 23.59.60 1998

are two. First, they cannot be calculated with. They are either
diagnosed as in error or yield incorrect arithmetic results.

Second, they work only for positive leap-second corrections. The data
came close to a yielding a negative correction, the subtraction of a
leap second from the current total, several years ago; one is now very
likely, all but certain, very soon; and the analogue of this offensive
notation for it is duplicative.

The whole notion that we need a calendrical name for a correction,
that the correction is itself or needs to be a valid UTC value is
without merit. The use of the adjective 'leap' was, I suppose,
inevitable; but leap seconds are not in fact at all like leap-year
days or gravid, Hebrew-calendar months: we don't need calendrical
names for them.

[Tony Harminc]

On 8 July 2014 12:14, John Gilmore <jwgl...@gmail.com> wrote:
> The whole notion that we need a calendrical name for a correction,
> that the correction is itself or needs to be a valid UTC value is
> without merit. The use of the adjective 'leap' was, I suppose,
> inevitable; but leap seconds are not in fact at all like leap-year
> days or gravid, Hebrew-calendar months: we don't need calendrical
> names for them.

Surely the issue is not one of naming, but that an event can occur
during a leap second, and it must be possible -- and surely not
exceptional -- to talk about the time of this event, calculate how
long before or after another event it took place, and so on, all in
terms of the notation in question.

Tony H.

[Retired Mainframer]

On 7/7/2014 3:53 PM, Robert A. Rosenberg wrote:
> OOPS. I might have it backwards but my principle still stands. There
> only ambiguous time stamp is the switch day when the 1AM hour can
> occur twice. On that day when you see get to 1:59AM and roll back to
> 1:00AM again (and thus see timestamps in the 1:xxAM hour earlier than
> a previous timestamp) you know to adjust the UTC offset. When you skip
> the 2:xxAM hour then you know to use the correct offset for 12M to
> 1:59AM and to switch to the other offset when you see 3:00AM.
>

For data produced near the "fall back" event:

If the input data is not ordered chronologically (if a 0415 datum
can follow a 0430 datum), then a 0115 datum following a 0130 datum tells
you nothing about which offset to use for either.

If the data is not reasonably dense, then a 0130 datum following a
0030 datum tells you nothing about which offset to use for the former.

[Jim Mulder]

>Current UTC is got by subtracting the correction in CVTLSO from the
>value returned by STCK. I know of no z/OS supplied facility that
>correctly converts historic TOD values to UTC. (It's not clear
>whether STCKCONV does this; IBM refuses to provide detailed documentation
>of the behavior of STCKCONV, calling it "common knowledge". IMO,
>"common knowledge" without even a citation is a shabby alternative
>to documentation.)

I will tell you exactly what STCKCONV does.
It subtracts CVTLSO (obtained from the CVT of the system where
STCKCONV is being executed) from the input you provide,
It then adds CVTLDTO.

STCKCONV has no knowledge of historical leap second values.
z/OS obtains the current value for CVTLSO from the
machine via an internal ETR/STP interface. This interface does not
provide a table of historical values.

If your program requires historical correctness, it could maintain a
historical table of leap second values, and compute the difference
between the number of leap seconds in effect at the date of your
historical TOD value and the number of leap seconds for the
current date. Convert that number of seconds of difference to timer
units (by multiplying by 1,000,000 (microseconds per second) *
4096 (timer units per microsecondsecond) ). Add this number of
timer units to your historical time stamp, and pass the result to
STCKCONV.

Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY(845) 435-4741
(T/L 295) M/S P351

[Paul Gilmartin]

On 2014-07-09 13:55, Jim Mulder wrote:
>> Current UTC is got by subtracting the correction in CVTLSO from the
>> value returned by STCK. I know of no z/OS supplied facility that
>> correctly converts historic TOD values to UTC. (It's not clear
>> whether STCKCONV does this; IBM refuses to provide detailed documentation
>> of the behavior of STCKCONV, calling it "common knowledge". IMO,
>> "common knowledge" without even a citation is a shabby alternative
>> to documentation.)
>
> I will tell you exactly what STCKCONV does.
> It subtracts CVTLSO (obtained from the CVT of the system where
> STCKCONV is being executed) from the input you provide,
> It then adds CVTLDTO.
>
> STCKCONV has no knowledge of historical leap second values.
> z/OS obtains the current value for CVTLSO from the
> machine via an internal ETR/STP interface. This interface does not
> provide a table of historical values.
>

Does it also fail to provide a table of historical CVTLDTO values?
If so, it's an hour off a mere few months ago, on the other side of
the Daylight Saving Time boundary; so much worse.

> If your program requires historical correctness, it could maintain a
> historical table of leap second values, and compute the difference
> between the number of leap seconds in effect at the date of your
> historical TOD value and the number of leap seconds for the
> current date. Convert that number of seconds of difference to timer
> units (by multiplying by 1,000,000 (microseconds per second) *
> 4096 (timer units per microsecondsecond) ). Add this number of
> timer units to your historical time stamp, and pass the result to
> STCKCONV.
>

Why should each programmer need to do this? Some of them are sure to
get it wrong. Better such a table should be incorporated in STCKCONV.

But, have you checked the source code? My test program shows
(CONV is my macro to use
STCKCONV STCKEVAL=&STCKEVAL,CONVVAL=PK, x
DATETYPE=YYYYMMDD,TIMETYPE=DEC,MF=(E,SPLIST)
to convert then format and print the STCKE argument.)
*
* Circa December, 2008 Leap Second 24, per PoOp.
*
CONV =X'00C3870CB9BB5FFFFFFFFFFFFFFFFFFF'
CONV =X'00C3870CB9BB60000000000000000000'
Prints:
2009-01-01 00:00:23.999999
2009-01-01 00:00:24.000000
... off by 24 seconds because our site runs with CVTLSO=0 because
too much software from vendors (including IBM) yields inconsistent
results with CVTLSO set correctly.

*
* End of the World.
CONV =X'01000000000000000000000000000000'
CONV =X'01FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF'
Prints:
1900-01-01 00:00:00.000000
2042-09-17 23:53:47.370495
... showing mostly that STCKCONV (as of z/OS 1.13) has not yet
implemented the (proposed) use of the high byte of STCKE when
the ETOD clock wraps.

*
TIME STCKE,CLK5,LINKAGE=SYSTEM,MF=(E,W.TPLIST)
CONV CLK5
*
STCKE CLK5
CONV CLK5
Prints:
2014-07-09 23:05:44.299901
2014-07-09 23:05:44.299921
... the job log shows "17.05.44 JOB05935 $HASP395 HELLO ENDED"
Hmmm... Our CVTLDTO here in sunny Colorado today is -6 hours.
It appears that STCKCONV is *not* applying CVTLDTO. (And I've
learned that the conversion took 20 microseconds.)

But, I believe that when programmers as sophisticated as you and
I (I'll not presume to call myself in your class) can have
misconceptions about the operation of STCKCONV, Peter Relson is
wrong to call it "common knowledge", not needing further explanation.

It does give correct GMT for dates prior to 1972. Perhaps someone
merely forgot to update it when UTC came on the scene.

-- gil

[Jim Mulder]

Well, I did check the code, but not carefully enough. The
code in question is used by both the TIME macro when LINKAGE=SYSTEM
is specified, and the STCKCONV macro. Upon closer inspection,
the code dealing with CVTLSO and CVTLDTO is on a path used only
for TIME with LINKAGE=SYSTEM. STCKCONV does not do anything
with CVTLDTO and CVTLSO, or attempt any kind of leap second
or time zone adjustment. The caller must make
any such desired adjustments before calling STCKCONV.

> *
> * End of the World.
> CONV =X'01000000000000000000000000000000'
> CONV =X'01FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF'
> Prints:
> 1900-01-01 00:00:00.000000
> 2042-09-17 23:53:47.370495
> ... showing mostly that STCKCONV (as of z/OS 1.13) has not yet
> implemented the (proposed) use of the high byte of STCKE when
> the ETOD clock wraps.

In z/OS 2.1, STCKCONV does handle x'01' on the high byte of
an STCKE value (thanks to Peter Relson).

> *
> TIME STCKE,CLK5,LINKAGE=SYSTEM,MF=(E,W.TPLIST)
> CONV CLK5
> *
> STCKE CLK5
> CONV CLK5
> Prints:
> 2014-07-09 23:05:44.299901
> 2014-07-09 23:05:44.299921
> ... the job log shows "17.05.44 JOB05935 $HASP395 HELLO ENDED"
> Hmmm... Our CVTLDTO here in sunny Colorado today is -6 hours.
> It appears that STCKCONV is *not* applying CVTLDTO. (And I've
> learned that the conversion took 20 microseconds.)
>
> But, I believe that when programmers as sophisticated as you and
> I (I'll not presume to call myself in your class) can have
> misconceptions about the operation of STCKCONV, Peter Relson is
> wrong to call it "common knowledge", not needing further explanation.
>
> It does give correct GMT for dates prior to 1972. Perhaps someone
> merely forgot to update it when UTC came on the scene.

I don't know that I have ever been considered to be a
"sophisticated programmer" - mostly known around IBM as a dump reader.
I haven't ever used STCKCONV - it did not exist until SP4.1.0
(around 1990), so the code I have worked on which
needs to do timestamp conversion (mostly code which runs under
IPCS) instead uses the BLSUxTOD services supplied by IPCS.
The BLSUxTyD services also do not do any leap second or time
zone adjustments. I just looked into STCKCONV today to try to answer
your questions while Peter is on vacation.

If you feel that the STCKCONV documentation should be updated
to explicitly say that STCKCONV does not do any leap second or time
zone adjustments, I would suggest submitting a Reader's Comment Form.

[John Gilmore]

STCKCONV should not be altered; it should do what it has always done.
Too much existing code woulfd be broken by changing its behavior now.

Another facility, call it say STCK2UTC, could usefully be defined on
top of it; but that is another matter.

Maintenance for a table of STCKE values and their corresponding
cumulative leap-second counts is unproblematic; The IERS provides,
minimally, six months' notice of impending leap-second corrections;
and automated BIPM notifications of these corrections are also
available.

I have a literally exhaustively tested, much used PL/I procedure that
does GLB-seeking binary search in a self-defining STCKE table
available; and I should be happy to send a copy of the source code for
it to anyone who wants it. (It could be converted to C or another
C-like language without much difficulty. Its chief "limitation" is
that it deals only in STCKE, not STCK values.)

[Ed Jaffe]

On 7/9/2014 11:04 PM, Jim Mulder wrote:
> Upon closer inspection,
> the code dealing with CVTLSO and CVTLDTO is on a path used only
> for TIME with LINKAGE=SYSTEM. STCKCONV does not do anything
> with CVTLDTO and CVTLSO, or attempt any kind of leap second
> or time zone adjustment.

THANK GOD!! You scared me with your previous post!

We call STCKCONV in *many* places assuming it is a straight conversion
with no time zone adjustments made.

Whew! :)

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

[Paul Gilmartin]

On 2014-07-10, at 08:34, Ed Jaffe wrote:

> On 7/9/2014 11:04 PM, Jim Mulder wrote:
>> Upon closer inspection,
>> the code dealing with CVTLSO and CVTLDTO is on a path used only
>> for TIME with LINKAGE=SYSTEM. STCKCONV does not do anything
>> with CVTLDTO and CVTLSO, or attempt any kind of leap second
>> or time zone adjustment.
>
> THANK GOD!! You scared me with your previous post!
>
> We call STCKCONV in *many* places assuming it is a straight conversion with no time zone adjustments made.
>
> Whew! :)
>

"Assuming", because it's not documented, and you (probably)
haven't the access to the source code that Jim has.

Does your code run on systems with CVTLSO<>0? Does the (now)
25 second offset from STCKCONV time to cause problems? Our
site chose to disable leap seconds because of vendor inconsistencies.
And when we had leap seconds enabled, I reported a disagreement
between times reported in IEBCOPY SYSPRINT and the job log. IBM
fixed it by APAR.

-- gil

[George Kozakos]

>... showing mostly that STCKCONV (as of z/OS 1.13) has not yet
>implemented the (proposed) use of the high byte of STCKE when
>the ETOD clock wraps.

Support for the 2nd epoch was added in z/OS 2.1

Regards,
George Kozakos
z/OS Software Service, Level 2 Supervisor

[Paul Gilmartin]

On 2014-07-10 17:38, George Kozakos wrote:
>> ... showing mostly that STCKCONV (as of z/OS 1.13) has not yet
>> implemented the (proposed) use of the high byte of STCKE when
>> the ETOD clock wraps.
>
> Support for the 2nd epoch was added in z/OS 2.1
>

Yup. I tried it on a 2.1 system, and it seems good until about 2185.
I don't know why they didn't go for still more bits -- it's simplest
not to mask off any. But:

o It hardly matters.

o In the future, (some of) those additional 7 bits may be used for
purposes other than extending the range of the ETOD clock. But
I believe someone has pointed me to a publication saying that the
entire high byte of ETOD is already committed for that extended
(unsigned) range.

Long ago, I wondered why ETOD couldn't still be defined as signed;
it seems to me that CE 1899 might be more useful than CE 38434 (or
so). At that time, I was told that there already existed a firm
specification that ETOD was a 128-bit (minus programmable area)
unsigned item. I suppose programmers might already be loading its
comparator with 16X'FF' to defer an interrupt ridiculously far.
(Is there an ETOD comparator register?)

Thanks,
gil