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.
On Fri, Jul 3, 2015 at 4:46 PM, Charles Mills <[email protected]> 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:[email protected]] On > Behalf Of Paul Gilmartin > Sent: Friday, July 03, 2015 2:24 PM > To: [email protected] > 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 [email protected] 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 [email protected] with the message: INFO IBM-MAIN
