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. My head hurts. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
