Re: TOD clock values, leap seconds and BLSUXTOD conversion service
I stand corrected. Thanks for decreasing my ignorance in this area with those links. Peter R., apologies for my mistaken understanding of the TOD clock value. I now much better appreciate your repeated statements about the TOD clock value being architecturally TAI - 10. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, December 29, 2018 1:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TOD clock values, leap seconds and BLSUXTOD conversion service On Fri, 28 Dec 2018 23:52:07 -0600, Paul Gilmartin wrote: >> ... >I believe otherwise. In order to avoid discontinuities at leap seconds of the >sort >that cause network failures: > > https://en.wikipedia.org/wiki/Leap_second#Examples_of_problems_associated_with_the_leap_second >the TOD clock runs (**at IBM's strong recommendation**) at a constant rate, >TAI - 10 seconds. (I know no clear documentation of this (can someone help >me?), >but inferred it by converting the hex values in the PoOps.) > Ah! Found it! 4.6.1.5 "z/Architecture Principles of Operation" IBM Library Server https://www.ibm.com/support/libraryserver_os390/BOOKS/DZ9ZR003/4.6.1.5?SHELF=ez2vse00=20040504121320 4.6.1.5 TOD Programmable Register ... For the same reasons, conversion between ETR time and UTC does not take into consideration the time adjustments prior to 1972, and, thus, ETR time differs from TAI by a fixed amount of 10 seconds. Because of the occurrence of 22 leap seconds, UTC now is behind TAI by 32 seconds. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
On Fri, 28 Dec 2018 23:52:07 -0600, Paul Gilmartin wrote: >> ... >I believe otherwise. In order to avoid discontinuities at leap seconds of the >sort >that cause network failures: > > https://en.wikipedia.org/wiki/Leap_second#Examples_of_problems_associated_with_the_leap_second >the TOD clock runs (**at IBM's strong recommendation**) at a constant rate, >TAI - 10 seconds. (I know no clear documentation of this (can someone help >me?), >but inferred it by converting the hex values in the PoOps.) > Ah! Found it! 4.6.1.5 "z/Architecture Principles of Operation" IBM Library Server https://www.ibm.com/support/libraryserver_os390/BOOKS/DZ9ZR003/4.6.1.5?SHELF=ez2vse00=20040504121320 4.6.1.5 TOD Programmable Register ... For the same reasons, conversion between ETR time and UTC does not take into consideration the time adjustments prior to 1972, and, thus, ETR time differs from TAI by a fixed amount of 10 seconds. Because of the occurrence of 22 leap seconds, UTC now is behind TAI by 32 seconds. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
On Sat, 29 Dec 2018 05:21:30 +, Farley, Peter x23353 wrote: >"A STCK value came from the clock and is not to be considered UTC time." > >Then what is STP/NTP (or whatever the current mechanism is named) supposed to >do? Isn't the entire point of a hardware clock-setting mechanism to set the >hardware clock to some agreed-upon and internationally-supported standard >time? Isn't that agreed-upon time (**at IBM's strong recommendation**) at >least UTC time? If so then STCK/STCKE/STCKF do indeed produce UTC time as a >function of the IBM-chosen hardware epoch. QED. > I believe otherwise. In order to avoid discontinuities at leap seconds of the sort that cause network failures: https://en.wikipedia.org/wiki/Leap_second#Examples_of_problems_associated_with_the_leap_second the TOD clock runs (**at IBM's strong recommendation**) at a constant rate, TAI - 10 seconds. (I know no clear documentation of this (can someone help me?), but inferred it by converting the hex values in the PoOps.) So I believe that STCK followed by STCKCONV will return TAI - 10 seconds at the instant of the STCK. Not very useful, nor intuitive. The more reason for documenting affirmatively, not merely stating what it *does*not*do*. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
"A STCK value came from the clock and is not to be considered UTC time." Then what is STP/NTP (or whatever the current mechanism is named) supposed to do? Isn't the entire point of a hardware clock-setting mechanism to set the hardware clock to some agreed-upon and internationally-supported standard time? Isn't that agreed-upon time (**at IBM's strong recommendation**) at least UTC time? If so then STCK/STCKE/STCKF do indeed produce UTC time as a function of the IBM-chosen hardware epoch. QED. As I said in my prior reply, I agree that the existing conversion services should not change. I have no argument with you on that subject. "Make the case . . . " The case is for IBM z/OS developers to make why to do it, not for its users to make for them. Have a little pride, make the system the best that it can be regardless of whether users think it is "needed" or not (many of us DO think it is "needed" but are in no political position to "make a case" to anyone). You seem to want user CIO's and CEO's to "make the case" for you to your management instead of z/OS developers making the case themselves, when user CIO's and CEO's couldn't care a fig for whether it's accurate or not, only whether it affects their yearly bonus or not. Don't subscribe to "the minimum necessary effort that is profitable" cavil. That rabbit-hole is endless and evil, even if it is the common corporate thinking these days. Subscribe instead to "the best that I can produce despite management roadblocks". You will be much happier for it, and in the end so will your management. >From my personal perspective, yes it is about "locale-ly correct" time. Human >users of the output from z/OS systems may indeed be able to "deal with it" >when the time is not "locale-ly correct", but it does not mean they are happy >to do so. A z/OS programmer's job is to make those people happy. So please >make z/OS programmers happy so they can make their users happy too. That is a >"win-win" in the current vernacular. And I am sorry, but I do not buy into the notion of "limited resources" at a multi-billion-dollar company. Your management can make just as much "resource" available as they think will affect their own yearly bonus. It's your job to make your management think that it does affect their bonus, not your users' job. Don't ask for a reason; create one that makes your management happy and then "just do it". Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Friday, December 28, 2018 2:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TOD clock values, leap seconds and BLSUXTOD conversion service There is an architectural definition of what a tick in bit 51 of the 64-bit TOD clock. Thus a given clock value (bits 0-51) represents the number of microseconds since the start of the epoch being used. It seems true that STCKCONV assumes the standard epoch. As I said, if that is not mentioned in the doc, I'd be in favor of doing so. A STCK value came from the clock and is not to be considered UTC time. Why then should STCKCONV which is converting an input STCK value (not an input UTC value) provide a UTC date/time? If you want to provide a UTC clock value, then you could presumably do so. Should the service(s) factor in leap seconds? It no longer matters. They could not be changed to do so, since it would be incompatible. They could be enhanced to do so with a new non-default option but there would have to be a business case for that, and at this point no one has come close to making one. Therefore the thing to do is to document the current behavior, for which I've already said that I'm OK with indicating that this does not factor in leap seconds. I think Gil indicated he had submitted, or would submit, an RCF. As far as I know, none of the BCP-provided time services (TIME, STCKCONV, CONVTOD, BLSUXTOD, etc) pay attention to leap seconds. Nor are they likely ever to do so, if only because no one wants to have to update them whenever a leap second "shows up". If you want a service that does something with a historical time stamp and leap seconds, make the case. It hasn't been made in all the years since the first leap second. Maybe that's because humans don't truly need to know that level of precision for "old dates". Is this discussion similar to the question about "local time"? I don't see many people trying to factor into a display of time/date from a historical time stamp just when day light savings kicked in or out. I think local time is considered to be for humans and that it is thought that humans can "deal with it". -- This message and any attachments are intended only for the use of the ad
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
On Fri, 28 Dec 2018 14:46:41 -0500, Peter Relson wrote: >I shouldn't have included "TIME" among the services I mentioned because >that's "current", not "historic" (so only has to deal with "current" leap >seconds) and because it does not let you choose STCK as the "zone" -- you > Not as the "xone", but as the format. >must choose between local and UTC, both of which are defined with respect >to leap seconds. > >Thus it must handle leap seconds, but also is not in the position of >needing update for a "new" leap second. > I believe STP does this magically, in CVTLSO. And user tasks are paused, magically, during a leap second. PoOps has tables of leap seconds, almost up-to-date. That's what TNLs used to be for. >And, in case you're wondering, at the "instant" of bringing in a new leap >second, there are various approaches in play that customers choose to >adopt and I doubt that it is deterministic on which side of the fence you >would necessarily fall if you used some service such as TIME (or if you >did it yourself) -- perhaps the STCK was done "just before" but reference >to CVTLSO was "just after". Something similar could happen with respect to >time zone offset changes. > Does TIME protect against this improbable occurrence? Remember Murphy! I can imagine only: RETRY: copy CVTLSO and CVTLDTO into private storage STCK compare copied values to CVTLSO and CVTLDTO BNE RETRY proceed with conversion Does TIME do something similar? Does STP serialize updates to CVTLSO and CVTLDTO? Does TIME use STCK or STCKF? Does this reload cache for the compare if necessary? Suspending user tasks during leap second doesn't help. Remember Murphy. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
One major consideration should be who sets the time zone. Many mainframes support users in multiple time zones. So ideally the mainframe should be set to UTC then the macro should convert to the local time of the individual application / user. On Fri, Dec 28, 2018 at 1:47 PM Peter Relson wrote: > > I shouldn't have included "TIME" among the services I mentioned because > that's "current", not "historic" (so only has to deal with "current" leap > seconds) and because it does not let you choose STCK as the "zone" -- you > must choose between local and UTC, both of which are defined with respect > to leap seconds. > Thus it must handle leap seconds, but also is not in the position of > needing update for a "new" leap second. > > And, in case you're wondering, at the "instant" of bringing in a new leap > second, there are various approaches in play that customers choose to > adopt and I doubt that it is deterministic on which side of the fence you > would necessarily fall if you used some service such as TIME (or if you > did it yourself) -- perhaps the STCK was done "just before" but reference > to CVTLSO was "just after". Something similar could happen with respect to > time zone offset changes. > > Peter Relson > z/OS Core Technology Design > > > -- > 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: TOD clock values, leap seconds and BLSUXTOD conversion service
I agree with the comments on what should have been done, and I agree that the documentation needs to be corrected. However, I also agree with IBM that they should not introduce an incompatibility and that any enhancement to TOD conversion requires a business case. A starting point might be to research the acceptability of z/OS Unix System Service (*NOT* USS!) to the *ix community and the effect of that on z sales. With regard to whether z/OS is UNIX, I must reluctantly agree that it is, albeit without many of the facilities that the community expects. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Friday, December 28, 2018 12:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TOD clock values, leap seconds and BLSUXTOD conversion service Peter, I really must speak up here in defense of Paul/Gil's long time position on the failings of the STCKCONV/CONVTOD services. Firstly, you are not correct that "no one agrees with" Paul/Gil's position on the values produced by STCKCONV. There are at least some of us out here who agree with his position wholeheartedly. Our failing is not to have spoken up in his defense previously to now. Contrary to your opinion, Paul/Gil's use of "correct" is factually correct. People (including programmers) may reasonably expect that a request to convert a machine-based time value to "the local time" should produce an accurate representation of that local time. Similarly, if a programmer asks for a conversion of a machine-based time value to GMT/UTC/TAI or other time standard then they should get what was requested. Whatever architectural basis is used for the epoch at the machine level, the result of requesting a conversion of that hardware time measurement into human-intelligible format must produce "the correct time" according to the locale-ly correct standard, including "daylight savings" or "summer time" variations and also leap seconds. STCKCONV and CONVTOD perform neither of these functions, and should long since have been clearly documented as not performing them. In this sense, Paul/Gil's assertion that these services only produce accurate values prior to 1972 is factually accurate in one sense, since before 1972 we had no leap seconds. Paul/Gil is of course not totally accurate either, in that since the values produced by these services never did take locale-specific DST variations into consideration, by the rule of "locale-ly correct" even values prior to 1972 are not accurately converted. Paul/Gil's oft-expressed desire for IBM to fully support the Olson time database (I think I have that name correct, but please correct me if I do not), the "tz" timezone database that is regularly updated and supported across (most of) the rest of the computing world is something that I agree should have been done by IBM a very long time ago, especially since "z/OS is Unix" is an oft-repeated claim. If you do not support the Unix time database standard then you are not (entirely) Unix. And I frankly care not a whig whether it is POSIXly correct to say that or not. It does not conform to the commonly understood Unix time standard among programmers around the world. Period. Simply documenting the obvious failure of the STCKCONV/CONVTOD services to support leap seconds and locale-specific DST rules in any form is the very least that IBM should do. I can agree with your (I think unstated, or perhaps only stated infrequently) opinion that the STCKCONV/CONVTOD services themselves should not change to support time conversion features that they do not currently support. Too many compatibility and support issues to count. That there should be a new pair of services with enhanced capabilities available as alternatives to STCKCONV and CONVTOD, which new services actively use the "tz" database and correctly adjust any conversion for leap seconds as well as locale-dependent DST issues would be an obvious (to me) solution, along with carefully documenting STCKCONV's/CONVTOD's limitations in these areas. As for current LE provided time/date services, a brief RTFM reveals that many of them seem to use a different epoch than the (E)TOD clock, specifically 00:00:00 14 October 1582 according to the current LE Programming Reference. And only one of those services (CEEGMTO) purports to know the difference between local time and GMT time. Most confusing. All opinions expressed here are purely my own, and not my employer's. With utmost respect and admiration for your continued activity in this forum and for your gentlemanly responses here, Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Thursday, December 27, 2018 9:30
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
I shouldn't have included "TIME" among the services I mentioned because that's "current", not "historic" (so only has to deal with "current" leap seconds) and because it does not let you choose STCK as the "zone" -- you must choose between local and UTC, both of which are defined with respect to leap seconds. Thus it must handle leap seconds, but also is not in the position of needing update for a "new" leap second. And, in case you're wondering, at the "instant" of bringing in a new leap second, there are various approaches in play that customers choose to adopt and I doubt that it is deterministic on which side of the fence you would necessarily fall if you used some service such as TIME (or if you did it yourself) -- perhaps the STCK was done "just before" but reference to CVTLSO was "just after". Something similar could happen with respect to time zone offset changes. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
There is an architectural definition of what a tick in bit 51 of the 64-bit TOD clock. Thus a given clock value (bits 0-51) represents the number of microseconds since the start of the epoch being used. It seems true that STCKCONV assumes the standard epoch. As I said, if that is not mentioned in the doc, I'd be in favor of doing so. A STCK value came from the clock and is not to be considered UTC time. Why then should STCKCONV which is converting an input STCK value (not an input UTC value) provide a UTC date/time? If you want to provide a UTC clock value, then you could presumably do so. Should the service(s) factor in leap seconds? It no longer matters. They could not be changed to do so, since it would be incompatible. They could be enhanced to do so with a new non-default option but there would have to be a business case for that, and at this point no one has come close to making one. Therefore the thing to do is to document the current behavior, for which I've already said that I'm OK with indicating that this does not factor in leap seconds. I think Gil indicated he had submitted, or would submit, an RCF. As far as I know, none of the BCP-provided time services (TIME, STCKCONV, CONVTOD, BLSUXTOD, etc) pay attention to leap seconds. Nor are they likely ever to do so, if only because no one wants to have to update them whenever a leap second "shows up". If you want a service that does something with a historical time stamp and leap seconds, make the case. It hasn't been made in all the years since the first leap second. Maybe that's because humans don't truly need to know that level of precision for "old dates". Is this discussion similar to the question about "local time"? I don't see many people trying to factor into a display of time/date from a historical time stamp just when day light savings kicked in or out. I think local time is considered to be for humans and that it is thought that humans can "deal with it". Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
For a contrary opinion, I believe IBM's documentation and function of the TOD clock to be quite adequate. The provided macros do the fairly involved arithmetic to convert a TOD number as-is, which is the most useful option. Adjusting for leap seconds, DST, and time zone can easily be done before conversion to a date/timestamp. If all those were built-in, you'd need several additional parameters to the macros to account for whether those operations were needed or not. That would complicate things for no particular benefit. Regardless, if that's the function you want, then bid for it, or write it and sell it. IBM evidently doesn't see the business proposition, so prove them wrong. For me, I'd just as soon code the 2-3 extra instructions myself and know that I understand exactly what's happening. sas On Fri, Dec 28, 2018 at 12:46 AM Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > Peter, > > I really must speak up here in defense of Paul/Gil's long time position on > the failings of the STCKCONV/CONVTOD services. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
Peter, I really must speak up here in defense of Paul/Gil's long time position on the failings of the STCKCONV/CONVTOD services. Firstly, you are not correct that "no one agrees with" Paul/Gil's position on the values produced by STCKCONV. There are at least some of us out here who agree with his position wholeheartedly. Our failing is not to have spoken up in his defense previously to now. Contrary to your opinion, Paul/Gil's use of "correct" is factually correct. People (including programmers) may reasonably expect that a request to convert a machine-based time value to "the local time" should produce an accurate representation of that local time. Similarly, if a programmer asks for a conversion of a machine-based time value to GMT/UTC/TAI or other time standard then they should get what was requested. Whatever architectural basis is used for the epoch at the machine level, the result of requesting a conversion of that hardware time measurement into human-intelligible format must produce "the correct time" according to the locale-ly correct standard, including "daylight savings" or "summer time" variations and also leap seconds. STCKCONV and CONVTOD perform neither of these functions, and should long since have been clearly documented as not performing them. In this sense, Paul/Gil's assertion that these services only produce accurate values prior to 1972 is factually accurate in one sense, since before 1972 we had no leap seconds. Paul/Gil is of course not totally accurate either, in that since the values produced by these services never did take locale-specific DST variations into consideration, by the rule of "locale-ly correct" even values prior to 1972 are not accurately converted. Paul/Gil's oft-expressed desire for IBM to fully support the Olson time database (I think I have that name correct, but please correct me if I do not), the "tz" timezone database that is regularly updated and supported across (most of) the rest of the computing world is something that I agree should have been done by IBM a very long time ago, especially since "z/OS is Unix" is an oft-repeated claim. If you do not support the Unix time database standard then you are not (entirely) Unix. And I frankly care not a whig whether it is POSIXly correct to say that or not. It does not conform to the commonly understood Unix time standard among programmers around the world. Period. Simply documenting the obvious failure of the STCKCONV/CONVTOD services to support leap seconds and locale-specific DST rules in any form is the very least that IBM should do. I can agree with your (I think unstated, or perhaps only stated infrequently) opinion that the STCKCONV/CONVTOD services themselves should not change to support time conversion features that they do not currently support. Too many compatibility and support issues to count. That there should be a new pair of services with enhanced capabilities available as alternatives to STCKCONV and CONVTOD, which new services actively use the "tz" database and correctly adjust any conversion for leap seconds as well as locale-dependent DST issues would be an obvious (to me) solution, along with carefully documenting STCKCONV's/CONVTOD's limitations in these areas. As for current LE provided time/date services, a brief RTFM reveals that many of them seem to use a different epoch than the (E)TOD clock, specifically 00:00:00 14 October 1582 according to the current LE Programming Reference. And only one of those services (CEEGMTO) purports to know the difference between local time and GMT time. Most confusing. All opinions expressed here are purely my own, and not my employer's. With utmost respect and admiration for your continued activity in this forum and for your gentlemanly responses here, Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Thursday, December 27, 2018 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TOD clock values, leap seconds and BLSUXTOD conversion service OK. You're correct in your pedantry; it does not assert that the time output by these services corresponds to the input values -- it guarantees only the format. I still feel that statements such as this entice a programmer to that misbelief. You have been saying the same thing for years, with no one apparently agreeing with you. The "time output by these services" corresponds exactly to the input values, according to an architectural definition. That is what you have been told you multiple times. , There is an assumption of using the standard epoch (if that assumption is not mentioned, I'd support mentioning it). Would you be willing to see added to this description a caution such as: Note: if the (E)TOD clock is set according to IBM's
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
On 28/12/2018 1:30 am, Peter Relson wrote: You have been saying the same thing for years, with no one apparently agreeing with you. I admit I am also confused by these discussions. What value does STCK followed by STCKCONV give at exactly midnight 28 December 2018 UTC? What value does TIME DEC return at exactly midnight 28 December 2018 UTC? Does TIME STCK followed by STCKCONV TIMETYPE=DEC give the same value as TIME DEC? The "time output by these services" corresponds exactly to the input values, according to an architectural definition. I am not aware of an architectural definition for the output time. I am perfectly happy with the microseconds since the start of the standard epoch definition for the TOD value, BUT I think most people would assume that the "time of day and date" output would correspond to the usual definitions of time of day and date. The amount of code that depends on this means that it is effectively impossible to change. However, if the value returned by STCK needs to be adjusted by leap seconds before STCKCONV to give what is commonly accepted as the time of day, that should be in the documentation. Andrew Rowley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
OK. You're correct in your pedantry; it does not assert that the time output by these services corresponds to the input values -- it guarantees only the format. I still feel that statements such as this entice a programmer to that misbelief. You have been saying the same thing for years, with no one apparently agreeing with you. The "time output by these services" corresponds exactly to the input values, according to an architectural definition. That is what you have been told you multiple times. , There is an assumption of using the standard epoch (if that assumption is not mentioned, I'd support mentioning it). Would you be willing to see added to this description a caution such as: Note: if the (E)TOD clock is set according to IBM's recommendation, the times output by STCKCONV and CONVTOD do not match the input values, but may differ according to the content of various common control blocks. ? No I would not. Because it is not true, unless I am misunderstanding. What was the objective of providing these two services? I do not know. They meet the needs of whoever is using them currently. They give correct results only for dates before 1972, and I see little value in that. I believe that they give correct results in 100% of cases. I think that it is your use of "correct" that is not correct. I have already mentioned being willing to document that leap seconds are not taken into account. Anyone who needs leap seconds to be taken into account can adjust their STCK value accordingly. If you were to ask for a system service that would do that adjustment, under the assumption of use of the standard epoch, a service that would be adjusted every time a leap second is added, that would be reasonable. I suspect (without knowledge) that there already are ways of getting that done either through LE or USS. Of course "reasonable" does not equate to "likely to happen" Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
On Wed, 26 Dec 2018 09:00:47 -0500, Peter Relson wrote: > >>I believe a programmer might reasonably expect that STCKCONV usefully return >>whatever TIME would have returned at the instant of the STCK. > >A programmer would expect next to nothing due to the name of a service >since it is not possible to define much in the way of expectations with only 8 >bytes of name. >A programmer would read the description to understand what a service does. > From: IBM MVS Programming: Assembler Services Reference, Volume 2 (IAR-XCT) Version 2 Release 3 SA23-1370-30 Chapter 107. TIME — Obtain time and date: ... You can use the STCKCONV and CONVTOD macros to convert between TOD-clock format and various time of day and date formats. The STCKCONV macro converts a TOD-clock value to a time of day and date value and the CONVTOD macro converts a time of day and date value to a TOD clock value. ... OK. You're correct in your pedantry; it does not assert that the time output by these services corresponds to the input values -- it guarantees only the format. I still feel that statements such as this entice a programmer to that misbelief. Would you be willing to see added to this description a caution such as: Note: if the (E)TOD clock is set according to IBM's recommendation, the times output by STCKCONV and CONVTOD do not match the input values, but may differ according to the content of various common control blocks. ? What was the objective of providing these two services? Did they address a User Requirement? Did they meet that requirement? They give correct results only for dates before 1972, and I see little value in that. >A programmer would wonder when they might want to use TIME and when they >might want to use STCKCONV, and base their decision on the service >definitions. >The difference is between "what date/time is it" and "what is the >date/time that a STCK value architecturally is" (which, ignoring bits >52-63, is the number of microseconds since the start of the standard >epoch). > An alternative statement might be: If the (E)TOD clock is set according to IBM's recommendation, and the input to STCKCONV is the result of STCK, the output of STCKCONV will be TAI minus 10 seconds. Conversely, if the input to TODCONV is a TAI value minus 10 seconds, the output will be the corresponding (E)TOD value. OK. You're right that the programmer is free to choose any epoch/origin. Yet it would be a courtesy to state, if only as an example, what the programmer can expect when choosing the origin recommended by IBM. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
>What date and time in 1900, and what time scale? GMT? UTC? UT1? Ephemeris tme? >Terrestrial dynamic time? ...? Surely you know that the principles of operation documents that a clock value of 0 is January 1, 1900 12:00 AM UTC (although I believe UTC did not exist as a term when this was defined; it was presumably GMT at that time), or the start of any subsequent epoch. >I believe a programmer might reasonably expect that STCKCONV usefully return >whatever TIME would have returned at the instant of the STCK. A programmer would expect next to nothing due to the name of a service since it is not possible to define much in the way of expectations with only 8 bytes of name. A programmer would read the description to understand what a service does. A programmer would wonder when they might want to use TIME and when they might want to use STCKCONV, and base their decision on the service definitions. The difference is between "what date/time is it" and "what is the date/time that a STCK value architecturally is" (which, ignoring bits 52-63, is the number of microseconds since the start of the standard epoch). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
On Sat, 15 Sep 2018 08:52:55 -0400, Peter Relson wrote: > >On Sat, 20 Apr 2013 14:39:08 -0400, Peter Relson wrote: >>... The documentation says "The STCKCONV macro converts an input >>time-of-day (TOD) clock value to time of day and date, and returns the >>converted values to the caller in the format requested. " This is correct >>and is complete and is all that the service can say. > >As has been mentioned before, there is no reason to talk about a timezone >in this context. >A time-of-day clock value is a time-of-day clock value. That value is >defined in PoP. Since 0 represents 1900 and since bit 51 ticks every >microsecond, bits 0-51 form a number that is the number of microseconds >since 1900. > What date and time in 1900, and what time scale? GMT? UTC? UT1? Ephemeris tme? Terrestrial dynamic time? ...? I believe a programmer might reasonably expect that STCKCONV usefully return whatever TIME would have returned at the instant of the STCK. >I'd be quite happy to have the documentation clarify that the conversion >does not account for leap seconds. RCF submitted. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
"Usually" is slippery. When you need it, it's important. And if someone truly needs it, then they should make a business case and submit an RFE for it. > and even a bad idea to save UTC time, as opposed to saving the >STCK(E) value. > Why? Perhaps because of the lack of processing of leap seconds. Those data are readily available. The work is already done for you: https://www.iana.org/time-zones One thing that is missing is any intrinsic knowledge of exactly where the data was collected such as which time zone, which country, which state, whatever. On Sat, 20 Apr 2013 14:39:08 -0400, Peter Relson wrote: >... The documentation says "The STCKCONV macro converts an input >time-of-day (TOD) clock value to time of day and date, and returns the >converted values to the caller in the format requested. " This is correct >and is complete and is all that the service can say. > I (and apparently you) disagree about "complete". The doc could at least specify timezone. It seems to be, "none, rather TAI-27 seconds.) You continue to make this (to me) unfounded statement. As has been mentioned before, there is no reason to talk about a timezone in this context. A time-of-day clock value is a time-of-day clock value. That value is defined in PoP. Since 0 represents 1900 and since bit 51 ticks every microsecond, bits 0-51 form a number that is the number of microseconds since 1900. I'd be quite happy to have the documentation clarify that the conversion does not account for leap seconds. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: TOD clock values, leap seconds and BLSUXTOD conversion service
On Fri, 14 Sep 2018 22:34:09 +0200, Peter Hunkeler wrote: > >>There is nothing in error with any of the conversion services. They do >what they intend to do. And yes they do the easy part. > >Is that clear from the description of the service? At least for BLSUXTOD I >can't remember to have read about that fact. > (Concerning the similar STCKCONV): On Sat, 20 Apr 2013 14:39:08 -0400, Peter Relson wrote: >... The documentation says "The STCKCONV macro converts an input >time-of-day (TOD) clock value to time of day and date, and returns the >converted values to the caller in the format requested. " This is correct >and is complete and is all that the service can say. > I (and apparently you) disagree about "complete". The doc could at least specify timezone. It seems to be, "none, rather TAI-27 seconds.) >>What there is is a lack of functionality that would usually be unimportant to >>have. > >Usually unimportant Hmmm. Suppose, I have a case to chase where z/OS as >well as some non-mainframe parts are involved. Looking at a SYSTRACE of a >related dump. Timestamps show by IPCS and those from somewhere else are, as of >the last leap-second, 27 seconds apart. > >I don't say I had bee burnt by such a case, yet. But I would not state this >fact as unimportant. >I can live with this. I'm just surprised. See Peter Farley's rhetorical plaint here a couple hours ago. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
The Earth is expected to have a 25 hour day in 200 Million years. https://www.express.co.uk/news/science/741074/25-hour-day-earth-orbit-slowing Dividing by the number of seconds in an hour (3600) gives us 55,555.556 years until every day is 24 hours and 1 second long. Dividing by the number of days in a year gives us 152.20 years until we need 1 leap second every year. So after several decades from the reference year we are doing a leap second about every 3rd year, so about 78? 1950? 12 leap seconds would be 1826.48 years until we need 1 leap second per month. All subject to orbital variations. On Fri, Sep 14, 2018 at 2:39 PM Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > On Fri, 14 Sep 2018 09:14:25 -0700, Charles Mills wrote: > > >I believe that is in fact in the standard. > > > The best I easily find is: > https://www.iers.org/IERS/EN/Science/EarthRotation/UTC.html > ... > UTC is defined by the CCIR Recommendation 460-4 (1986). It differs from > TAI by an integer number of seconds, in such a way that UT1-UTC stays > smaller than 0.9s in absolute value. The decision to introduce a leap > second > in UTC to meet this condition is the responsibility of IERS (Bulletin C). > According to the CCIR Recommendation, first preference is given to the > opportunities at the end of December and June, and second preference to > those at the end of March and September. Since the system was introduced > in 1972 only dates in June and December have been used. > > I don't see any mention of more than 12 leap seconds within a year. I'd > rather > expect up to every month, then half-month, then daily, then hourly. A > 62-second > minute would be a desperate last resort. > > The ANSI C standard generously, or probably naively allows 62-second minutes. > > UTC1-UTC grows quadratically so it'll happen sooner than you expect. > https://en.wikipedia.org/wiki/%CE%94T > (I guess that's a parabola.) > > >-Original Message- > >From: Mike Schwab > >Sent: Friday, September 14, 2018 7:37 AM > >> > >> ... The UTC specification deals with that by requiring the value > >> 23:59:60.xxx during a leap second. The sequence of events is > >> well-determined. > > > >So, after a few thousand years and all days have 23:59:60 we will > >start having leap days lasting until 23:59:61? > > -- gil > > -- > 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
AW: Re: TOD clock values, leap seconds and BLSUXTOD conversion service
>There is nothing in error with any of the conversion services. They do what they intend to do. And yes they do the easy part. Is that clear from the description of the service? At least for BLSUXTOD I can't remember to have read about that fact. >What there is is a lack of functionality that would usually be unimportant to >have. Usually unimportant Hmmm. Suppose, I have a case to chase where z/OS as well as some non-mainframe parts are involved. Looking at a SYSTRACE of a related dump. Timestamps show by IPCS and those from somewhere else are, as of the last leap-second, 27 seconds apart. I don't say I had bee burnt by such a case, yet. But I would not state this fact as unimportant. I can live with this. I'm just surprised. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
On Fri, 14 Sep 2018 19:26:55 +, Farley, Peter x23353 wrote: > >As Gil has mentioned more than once, the z/OS failure to support and use the >IANA Timezone package and database is the issue here. > >Using the IANA Timezone database would solve all of his issues and many others >and be a plus for z/OS Unix conforming to widely used and rspected standards >as well. > Alas, not quite. POSIX is the fly in the ointment by simultaneously requiring UTC and prohibiting leap seconds, a logical impossibility. My favorite absurdity: http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html ... it is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch. In hindsight, if I had been emperor of the IT universe those decades ago, I would have chosen UT1 rather than UTC. More practical and, in a sense, more predictable. >Can you answer the question of WHY the IANA Timezone database is not supported >as part of base z/OS Unix? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
On Fri, 14 Sep 2018 09:14:25 -0700, Charles Mills wrote: >I believe that is in fact in the standard. > The best I easily find is: https://www.iers.org/IERS/EN/Science/EarthRotation/UTC.html ... UTC is defined by the CCIR Recommendation 460-4 (1986). It differs from TAI by an integer number of seconds, in such a way that UT1-UTC stays smaller than 0.9s in absolute value. The decision to introduce a leap second in UTC to meet this condition is the responsibility of IERS (Bulletin C). According to the CCIR Recommendation, first preference is given to the opportunities at the end of December and June, and second preference to those at the end of March and September. Since the system was introduced in 1972 only dates in June and December have been used. I don't see any mention of more than 12 leap seconds within a year. I'd rather expect up to every month, then half-month, then daily, then hourly. A 62-second minute would be a desperate last resort. The ANSI C standard generously, or probably naively allows 62-second minutes. UTC1-UTC grows quadratically so it'll happen sooner than you expect. https://en.wikipedia.org/wiki/%CE%94T (I guess that's a parabola.) >-Original Message- >From: Mike Schwab >Sent: Friday, September 14, 2018 7:37 AM >> >> ... The UTC specification deals with that by requiring the value >> 23:59:60.xxx during a leap second. The sequence of events is >> well-determined. > >So, after a few thousand years and all days have 23:59:60 we will >start having leap days lasting until 23:59:61? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
Peter, As Gil has mentioned more than once, the z/OS failure to support and use the IANA Timezone package and database is the issue here. Using the IANA Timezone database would solve all of his issues and many others and be a plus for z/OS Unix conforming to widely used and rspected standards as well. Can you answer the question of WHY the IANA Timezone database is not supported as part of base z/OS Unix? Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Friday, September 14, 2018 8:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TOD clock values, leap seconds and BLSUXTOD conversion service As to this statement >z/OS shirks by shutting down user tasks during that second. "Shutting down user tasks" is not true in general that, but can be true depending on your time protocol. For the case where it is true, it should be apparent that no other approach could possibly work in order to accommodate dependencies upon timestamps to determine the sequence of events. Peter Relson z/OS Core Technology Design -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
I believe that is in fact in the standard. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Friday, September 14, 2018 7:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TOD clock values, leap seconds and BLSUXTOD conversion service On Fri, Sep 14, 2018 at 9:11 AM Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > False. The UTC specification deals with that by requiring the value > 23:59:60.xxx during a leap second. The sequence of events is > well-determined. > > -- gil So, after a few thousand years and all days have 23:59:60 we will start having leap days lasting until 23:59:61? -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
On Fri, Sep 14, 2018 at 9:11 AM Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > False. The UTC specification deals with that by requiring the value > 23:59:60.xxx during a leap second. The sequence of events is > well-determined. > > -- gil So, after a few thousand years and all days have 23:59:60 we will start having leap days lasting until 23:59:61? -- 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: TOD clock values, leap seconds and BLSUXTOD conversion service
On Fri, 14 Sep 2018 08:08:14 -0400, Peter Relson wrote: >There is nothing in error with any of the conversion services. They do >what they intend to do. And yes they do the easy part. What there is is a >lack of functionality that would usually be unimportant to have. > "Usually" is slippery. When you need it, it's important. >... it is generally a bad idea to save local time, > Yes. Someone should tell ISPF. > and even a bad idea to save UTC time, as opposed to saving the >STCK(E) value. > Why? >Sure, a service could be provided to convert a time stamp to one that >subtracts out the value corresponding to the leap seconds at the >particular time. >That service would have to be updated every time a leap second is added >which wouldn't be a big deal, but is work to do. >... >And that would only help for STCK(E) <--> UTC. Exactly when a time zone >offset change occurred is unknowable in general, so trying to figure out >the true local time based solely on a STCK(E) value cannot be done; >additional data would be needed. > Those data are readily available. The work is already done for you: https://www.iana.org/time-zones >As to this statement >>z/OS shirks by shutting down user tasks during that second. >"Shutting down user tasks" is not true in general that, but can be true >depending on your time protocol. > I understand that "shutting down user tasks" is part of the protocol IBM recommends. >For the case where it is true, it should be apparent that no other >approach could possibly work in order to accommodate dependencies upon >timestamps to determine the sequence of events. > False. The UTC specification deals with that by requiring the value 23:59:60.xxx during a leap second. The sequence of events is well-determined. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
There is nothing in error with any of the conversion services. They do what they intend to do. And yes they do the easy part. What there is is a lack of functionality that would usually be unimportant to have. There is expected to be some human understanding of the foibles of a human-readable report. It should be unimportant to a human what the exact local time (accounting for leap seconds as well as local time zone offset) local time or even the exact UTC time (accounting for leap seconds) was. What could well be of importance is the relative values of the STCK(E) value for two things. This is why it is generally a bad idea to save local time, and even a bad idea to save UTC time, as opposed to saving the STCK(E) value. Sure, a service could be provided to convert a time stamp to one that subtracts out the value corresponding to the leap seconds at the particular time. That service would have to be updated every time a leap second is added which wouldn't be a big deal, but is work to do. Make a business case and ask for such a service. I believe that no one has. And that would only help for STCK(E) <--> UTC. Exactly when a time zone offset change occurred is unknowable in general, so trying to figure out the true local time based solely on a STCK(E) value cannot be done; additional data would be needed. As to this statement >z/OS shirks by shutting down user tasks during that second. "Shutting down user tasks" is not true in general that, but can be true depending on your time protocol. For the case where it is true, it should be apparent that no other approach could possibly work in order to accommodate dependencies upon timestamps to determine the sequence of events. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
On Thu, 13 Sep 2018 20:00:25 -0400, George Kozakos wrote: > >The TOD clock value CF2D 54B4 FBA8 for July 1st, 2015 assuming >26 leap seconds are specified is correct: > >IP LTOD CF2D54B4FBA8 returns >07/01/2015 00:00:26.00 STCK X'CF2D54B4 FBA8' > >The PoP has been now updated with the leaps second value of 27 which >occurred January 1st, 2017 > Some years ago, I went to RCF, noting that the PoP contained two, perhaps three such tables of different recency. I said that these were unlikely to be kept synchronized unless they were merged into a single table. Rejected because the various tables contained different columns. I suppose they can't be merged into one table because that would be too wide to fit the 2-column format of PoP. G, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
> If I take the value for July 1st, 2015 from the PoP table and > subtract the equivalent of one second I understand this is the TOD > value for June 30 23:59:60. Am I mixing up things? The TOD clock values given in the PoPs correspond to a UTC time of 00:00:00 on the specified date assuming leap seconds are used. The TOD clock value CF2D 54B4 FBA8 for July 1st, 2015 assuming 26 leap seconds are specified is correct: IP LTOD CF2D54B4FBA8 returns 07/01/2015 00:00:26.00 STCK X'CF2D54B4 FBA8' The PoP has been now updated with the leaps second value of 27 which occurred January 1st, 2017 Regards, George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
On Thu, 13 Sep 2018 23:18:11 +0300, Binyamin Dissen wrote: > ... >It is not reading the clock, it is reading a value in the clock format. In my >code where the clock value will be logged, it is adjusted before being stored. > JM>and does not attempt to account for time zones or leap seconds. When you JM>use BLSUXTOD, you are expected to any adjustments of interest to you JM>before calling BLSUXTOD. >> >:>IOW, BLSUXTOD does the easy part and leaves the hard part for the user. >... >Adjusting the clock (if you know the difference) is quite easy code. > >:>When the user has a log with timestamps in TOD format and needs the >:>corresponding civil times, those adjustments must be made. It's unreasonable >:>to expect the user rather than the computer to do it. > >Yes, the computer code should do it before storing it. Completely agree. > o Does the TIME TOD macro perform that adjustment or leave it to the user? Why? o Is your practice typical? Do most applications/utilities logging times in TOD format use raw TOD, TOD adjusted by CVTLSO, TOD adjusted by CVTLSO and CVTLDTO, or other (specify)? Critical timestamps should be kept in UTC to avoid the Autumn ambiguity. But users may prefer that these be formatted in Local Time for display. What support does z/OS provide for this? It's routine in most other OSes. >:>It's time for z/OS to get its head out of the 20th Century. > >Relevance? > IBM seems to regard correct time values as irrelevant. A fun little script I tried on both MacOS and Linux: # Run this in a disposable directory. Use the following # to generate test data: : Leap seconds uncorrected -- time of recent leap second. TZ=GMT0 touch -t20170101.26 TAIfoo : List with leap seconds correction. TZ=right/GMT0 export TZ # For Linux: ls -l --time-style="+%F %T %z (%Z)" TAIfoo # For MacOS: ls -lT TAIfoo Shows (MacOS; similar on Linux): lsiso 16+ ls -lT TAIfoo -rw-r--r-- 1 paulgilm wheel 0 Dec 31 23:59:60 2016 TAIfoo Imagine! 23:59:60! z/OS shirks by shutting down user tasks during that second. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
On Thu, 13 Sep 2018 13:31:16 -0500 Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: :>On Thu, 13 Sep 2018 17:39:53 +0300, Binyamin Dissen wrote: :>>As this is part of the IPCS service, one wonders how it could determine the :>>TOD adjustment values for specified value. :>See: https://www.iana.org/time-zones :>On Thu, 13 Sep 2018 10:41:30 -0400, Jim Mulder wrote: :>> BLSUXTOD does not know the context of the TOD clock value you are passing, > :>Context? Shouldn't values of properly set TOD clocks read at the same time :>be identical world-wide? (I think we can ignore General Relativistic adjustments.) It is not reading the clock, it is reading a value in the clock format. In my code where the clock value will be logged, it is adjusted before being stored. :>>and does not attempt to account for time zones or leap seconds. When you :>>use BLSUXTOD, you are expected to any adjustments of interest to you :>>before calling BLSUXTOD. > :>IOW, BLSUXTOD does the easy part and leaves the hard part for the user. :>This appears to be the same defect as in STCKCONV and CONVTOD which, :>I suspect may be the underlying service. Adjusting the clock (if you know the difference) is quite easy code. :>When the user has a log with timestamps in TOD format and needs the :>corresponding civil times, those adjustments must be made. It's unreasonable :>to expect the user rather than the computer to do it. Yes, the computer code should do it before storing it. Completely agree. :>It's time for z/OS to get its head out of the 20th Century. Relevance? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
On Thu, 13 Sep 2018 17:39:53 +0300, Binyamin Dissen wrote: >As this is part of the IPCS service, one wonders how it could determine the >TOD adjustment values for specified value. > See: https://www.iana.org/time-zones On Thu, 13 Sep 2018 10:41:30 -0400, Jim Mulder wrote: > BLSUXTOD does not know the context of the TOD clock value you are passing, > Context? Shouldn't values of properly set TOD clocks read at the same time be identical world-wide? (I think we can ignore General Relativistic adjustments.) >and does not attempt to account for time zones or leap seconds. When you >use BLSUXTOD, you are expected to any adjustments of interest to you >before calling BLSUXTOD. > IOW, BLSUXTOD does the easy part and leaves the hard part for the user. This appears to be the same defect as in STCKCONV and CONVTOD which, I suspect may be the underlying service. When the user has a log with timestamps in TOD format and needs the corresponding civil times, those adjustments must be made. It's unreasonable to expect the user rather than the computer to do it. It's time for z/OS to get its head out of the 20th Century. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
BLSUXTOD does not know the context of the TOD clock value you are passing, and does not attempt to account for time zones or leap seconds. When you use BLSUXTOD, you are expected to any adjustments of interest to you before calling BLSUXTOD. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > So this is the first time I really care for leap seconds. I need a > conversion from TOD clock value to readable format in REXX. Found > the BLSUXTOD service. Works nice. so far so good. > > > The PoP has a table of TOD clock values taking care of the 26 leap > seconds inserted so far. The last one was inserted on June 30, 2015 > after 23:59:59. So there is a valid time stamp 23:59:60 on June > 30st, just before July 1st, 00:00:00. > > > If I take the value for July 1st, 2015 from the PoP table and > subtract the equivalent of one second I understand this is the TOD > value for June 30 23:59:60. Am I mixing up things? > > > If all is correct so far, I think BLSUXTOD is in error. It does not > take care of the leap seconds. For the above value, it returns July > 1st, 2015 00:00:25 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
As this is part of the IPCS service, one wonders how it could determine the TOD adjustment values for specified value. On Thu, 13 Sep 2018 15:59:40 +0200 Peter Hunkeler wrote: :>So this is the first time I really care for leap seconds. I need a conversion from TOD clock value to readable format in REXX. Found the BLSUXTOD service. Works nice. so far so good. :> :> :>The PoP has a table of TOD clock values taking care of the 26 leap seconds inserted so far. The last one was inserted on June 30, 2015 after 23:59:59. So there is a valid time stamp 23:59:60 on June 30st, just before July 1st, 00:00:00. :> :> :>If I take the value for July 1st, 2015 from the PoP table and subtract the equivalent of one second I understand this is the TOD value for June 30 23:59:60. Am I mixing up things? :> :> :>If all is correct so far, I think BLSUXTOD is in error. It does not take care of the leap seconds. For the above value, it returns July 1st, 2015 00:00:25 :> :> :>-- :>Peter Hunkeler :> -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
On Thu, 13 Sep 2018 15:59:40 +0200, Peter Hunkeler wrote: >So this is the first time I really care for leap seconds. I need a conversion >from TOD clock value to readable format in REXX. Found the BLSUXTOD service. >Works nice. so far so good. > >The PoP has a table of TOD clock values taking care of the 26 leap seconds >inserted so far. The last one was inserted on June 30, 2015 after 23:59:59. So >there is a valid time stamp 23:59:60 on June 30st, just before July 1st, >00:00:00. > >If I take the value for July 1st, 2015 from the PoP table and subtract the >equivalent of one second I understand this is the TOD value for June 30 >23:59:60. Am I mixing up things? > >If all is correct so far, I think BLSUXTOD is in error. It does not take care >of the leap seconds. For the above value, it returns July 1st, 2015 00:00:25 > Apparently. The TOD clock runs 10 seconds behind TAI; UTC is presently 35 (I'm sorta guessing.) That would account for 25 seconds. 26? http://hpiers.obspm.fr/eop-pc/index.php ... says 37. But: Last leap second: 31 December 2016 TAI - UTC: 37 s https://www.iana.org/time-zones ... is customary on most UNIX-like systems. z/OS doesn't use it. I've played with it on Linux. There's a directory hierarchy called "right" which appears to account for leap seconds. Injecting an artificial time() value as you did, I do see 23:59:60. It's time for z/OS to get its head out of the 20th Century. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
