"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 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
