On Fri, 3 Jul 2015 17:54:04 -0500, Mike Schwab wrote: >We could switch to a day is the time between actual solar noons. >Or adopt the ancient Hebrew definition of 12 hours of sunlight each >day and 12 hours of nighttime every day. > I've stated, and still hold, that UT1 would be a better, certainly more practical, standard for IT than UTC:
o There are no discontinuities o The conversion from UT1 seconds to YYYY-MM-DD hh:mm:ss can be performed predictably arbitrarily far into the future. o Surely, if Amazon, Google, and z/OS STP can slew their clocks by a second variously in 24 hours, 20 hours, and 7 hours, steering to earth rotation time is feasible. Unfortunately, POSIX chose to make two incompatible requirements: o The time standard is UTC. o Each day comprises 86,400 seconds. And systems programmers struggle to reconcile them. I say one must go. Discard UTC and keep consistent with earth rotation time. Conversions between UT1, UTC, TAI, GPS, ... are and would remain necessary. But UT1 is fine for the stamp on my ATM stub. I don't need atomic stability for that. "Smear" the leap second over several months rather than 7 hours. -- gil >On Fri, Jul 3, 2015 at 4:46 PM, Charles Mills <charl...@mcn.org> wrote: >>> I don't believe (but I've already been wrong once) that a programmer can >>> request a GMT or LT more than 4 months in the future. >> >> I think you're right. An LT or GMT STIMER pops the next time that time of >> day occurs, so it can be at most 23:59:59.99 away (23:59:60.99 counting leap >> seconds). >> >> Hey, there's one for you, Gil. One June 30, could one have set an STIMER GMT >> of 23:59:60.hh? (I think I know the answer.) >> >> The interval processing has no good answer IMHO. Sure, it seems like 4 >> seconds after 23:59:58 on June 30 should be 00:00:01, not :02 -- but how far >> do you carry that? What is 30 days after 23:59:58? Would you expect it to be >> 23:59:57 on July 30? To be consistent, it should be. >> >> Can a prisoner serving a 30-year sentence demand to be released 'n' seconds >> early to account for the leap seconds of incarceration? >> >> How long is a day? Is it exactly 24 hours, or is it variable, depending on >> what day you are talking about? >> >> Charles >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Paul Gilmartin >> Sent: Friday, July 03, 2015 2:24 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Leap Second today! >> >> On Fri, 3 Jul 2015 15:33:37 -0500, George Kozakos wrote: >>>> >>>> So it actually waits for 4 seconds rather than the 3 requested. >>> >>>The problem is that at 17:59:59 when the STIMER is processed we don't >>>know that a leap second will occur at 18:00. >>> >> Actually, you could have known that for 4 months, ever since the IERS >> announced the leap second. (Less the time it takes for a PTF to be created, >> distributed, and installed.) I don't believe (but I've already been wrong >> once) that a programmer can request a GMT or LT more than 4 months in the >> future. >> >> So, when a leap second occurs, scan the timer queue. You have nothing >> better to do; user programs are nondispatchable. >> >> o If an entry is for an interval, leave it alone. >> >> o If an entry is for GMT or LT, add a second and replace in >> the queue in proper order. >> >> At a Daylight Saving Time boundary, scan the queue. >> >> o If an entry is for an interval or GMT, leave it alone. >> >> o If an entry is for LT, subtract an hour in the Spring >> (It may pop immediately). In the Fall, add an hour >> If it's in the ambiguous hour, it will not pop for another >> hour. >> >> ---------------------------------------------------------------------- >> 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
