On Mon, 2 Jan 2017 18:40:32 -0600, Walt Farrell wrote: >>> >>>And we were not alone: >>>https://blog.cloudflare.com/how-and-why-the-leap-second-affected-cloudflare-dns/ >>> >>I read the article. The system involved duplicated the second at 23:59:59 >>so a time reading late in the first occurrence subtracted from a reading >>early in the second occurrence produced a negative elapsed time. A >>validity check failed and triggered a shutdown. > >Thanks. I didn't get that when I read the article. From a possibly naive >standpoint, I think the underlying system should have simply accepted >23:59:60, rather than duplicating 23:59:59. Obviously it recognized the >situation or it would have gone to 00:00:00 a second early, rather than >duplicating 23:59:59. > I confess I guessed at that. It may have duplicated the second at 00:00:00 instead. But the result would have been similar.
If it went to 00:00:00 a second early, i.e. at 23:59:60, would it then remain a second ahead of UTC forever? Whenever it elected to fall back into sync the hazard would occur. >So it's a broken lower-level function, requiring all the higher layers to work >around it. (Don't you often grumble at z/OS for that in other situations, gil?) > Sometimes I sneer at z/OS for sidestepping the problem by shutting down for the leap second and suggest that instead the TIME macro should return hh:59:60 for the duration. But sometimes I succumb to reality: o What additional software would need to be modified to accommodate? On a certain Linux system, I can set TZ=right/America/Denver, causing a selected time value to convert as 16:59:60. o What about POSIX, which effectively prohibits leap seconds? Practical IT standards should change. Either abandon UTC and switch to (smoothed) UT1 or adopt the Google/Amazon smear. The latter seems to be the modal approach. But what of z/OS? Either: o Abandon the atomic precision of TOD and steer it a few ppm. slow during the smear. Some applications require atomic precision. I suspect GPS is an example, or o Break the leap second into a thousand parts and adjust CVTLSO by a millisecond once a minute during the smear. But the system would still need to be shut down at each adjustment. Are a thousand service interruptions of a millisecond each preferable to a single interruption of an entire second? POSIX is internally inconsistent. It both requires UTC as a standard and requires that each day be exactly 86,400 seconds. >-- >Walt > >---------------------------------------------------------------------- >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
