[LEAPSECS] alternative to smearing

[John Sauter]

On Sat, 2017-01-07 at 09:38 -0500, Daniel R. Tobias wrote:
> On 6 Jan 2017 at 22:44, Hal Murray wrote:
> 
> > I think there are two different types of wait.  One is the simple
> > wait N 
> > seconds.  The other is wait until a specified date-time, say a
> > month from 
> > now.  They really are different so I don't see how to make your
> > "one 
> > interface" work.
> 
> It seems you can come up with quite a few "types of wait", or types 
> of scheduling for future events, appointments, announcements, and so 
> on, all of which ought to be supported in robust calendaring / 
> scheduling programs.
> 
> * Events scheduled for a fixed point relative to local civil time at 
> a specific place; its point in absolute time can change if time
> zones 
> or daylight saving rules shift. Most local events, work shifts, and 
> so on are like that.
> 
> * A fixed point relative to a particular named time zone, like "U.S. 
> Eastern time". National TV networks tend to schedule their
> broadcasts 
> this way. This won't shift in response to time zone boundary
> changes, 
> like if Indiana decides to change time zones between Eastern and 
> Central, but will reflect changes in daylight saving shift dates
> that 
> apply zone-wide.
> 
> * Fixed point relative to UTC; won't change for time zone and 
> daylight saving shifts, but will reflect leap seconds.
> 
> * Fixed point relative to a leapless atomic scale such as TAI or
> GPS; 
> its' place relative to UTC will shift for leap seconds, and its
> place 
> relative to local time will shift for leap seconds, daylight saving, 
> and time zone shifts.
> 
> * Interval-time wait by absolute number of SI seconds (ignoring 
> leaps, time zones, and the like).

I think a more common kind of wait is by number of SI seconds, ignoring
time zones but not leaps.  For example, if a device timeout is
specified as 5 seconds, you want to give it 5 seconds to respond, even
if one of those seconds is a leap second.

> * Interval-time wait by number of some larger unit such as minutes, 
> hours, days, or years as reckoned in some particular time scale; 
> there may be leaps built in to it.
> 
> Some of these can also be put into some turmoil if more drastic 
> calendar-system changes are made such as the Julian/Gregorian shift 
> (and any future such thing that might be needed millennia from now 
> when the current calendar proves astronomically inadequate).
> 

While the operating system and system libraries should provide support
for implementing all of these kinds of wait, the responsibility for
distinguishing them is in the application.  A scheduling application
given "03:00" needs to know whether the time is local or UTC, and if it
is local time whether "03:00" really means 3 AM or 3 hours after
midnight, the difference being due to daylight saving time.

An example of application-specific interval calculation is paychecks
for third-shift workers.  Labor law says workers get paid for the
number of hours they work, no matter what the clock says.  If I work
from midnight to 8 AM, I get paid for 8 hours on most days, but once a
year I get 9 hours pay for 9 hours of work, and once a year I get 7
hours pay for 7 hours of work.

Fortunately, leap seconds are small enough adjustments that the labor
laws don't care about them, or we would have to adjust a worker's pay
whenever a leap second fell on the worker's shift.
    John Sauter (John_Sauter at systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20170107/f18f3c2c/attachment.pgp>