I didn't know about leap smearing, so I read the links and was intringued. This is really a drive-by-comment. I'm sure I have better things to do.
Erik Kline via Datatracker <[email protected]> wrote: > ## Discuss > ### S4 > * "The second for date and time values MUST have the value "60" at > the end of months in which a leap second occurs." > I think this ties too strongly to an outmoded way of handling leap > seconds. It is widely documented by some cloud operators, for example, > that "leap smearing" can be employed [1, 2]. A scheduler taking time > from a leap smeared clock would never encode "60" at any time, nor > should it. Leap smearing would seem to more be about spreading the extra second across the entire month so that there is no "jump". So that anything that is doing calculations such as rate calculations doesn't have extra things to deal with. The schedule-yang seems to be about documenting events, either future ones (schedules), or past ones (which already occured). So it seems like someone want to schedule things to the leap second, and the smearing is for things that don't need to care so much. Even if leap smearing was done, a system using it might have to accept a start or end time where seconds==60. I think, someone might write: min-allowed-start: "2025-01-01T00:00:00" max-allowed-end: "2025-12-31T11:59:60" (if this year had a leap second) in order to represent the entire year. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
