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 ([email protected])
--
PGP fingerprint E24A D25B E5FE 4914 A603 49EC 7030 3EA1 9A0B 511E
signature.asc
Description: This is a digitally signed message part
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
