I understand that virtually nothing in the IETF outside of time synchronization protocols refers to non-UTC or non-civil time scales. I also understand it's too late at this juncture to contemplate adding a non-leap time scale to this document.
I do however think it's worth a few words about the limitations of scheduling whenever leap seconds are imminent. I'll put my thoughts into the IESG review, though. On Tue, Jul 29, 2025 at 12:16 PM <[email protected]> wrote: > Hi Erik, > > > > Thanks for the comment. > > > > The restriction you quoted was actually imported from rfc3339#section-5.7. > Also, we leverage base type (date-and-time) defined in 6991/6991bis: > > > > The date-and-time type is a profile of the ISO 8601 > > standard for representation of dates and times using the > > Gregorian calendar. The profile is defined by the > > date-time production in Section 5.6 of RFC 3339 and the > > update defined in Section 2 of RFC 9557 . The value of > > 60 for seconds is allowed only in the case of leap seconds. > > > > Unless I’m mistaken, even recent updates such as rfc9557 do not support > timescales other than UTC. > > > > Cheers, > > Med > > > > *De :* Erik Kline <[email protected]> > *Envoyé :* mercredi 23 juillet 2025 16:44 > *À :* [email protected] > *Objet :* [netmod] draft-ietf-netmod-schedule-yang and leap seconds > > > > > > <no hats/> > > > > All, > > > > (context: prompted by my question in TVR) > > > > I see that in draft-ietf-netmod-schedule-yang Section 4 it advises: > > > > * The second for date and time values MUST have the value "60" at > the end of months in which a leap second occurs. > > > > but I fear this is not sufficient. A scheduling entity in a data center > taking its time from a leap smearing [1, 2] source would probably not know > that this needs to be done, and its notion of time would be > subtly different over a span of (typically) 24 hours prior to the leap > second. > > > > Would it be possible to also include some time reference that doesn't have > to deal with leap seconds, like TAI [3, 4]? > > > > -ek > > > > [1] https://developers.google.com/time/smear > > [2] > https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/ > > [3] https://en.wikipedia.org/wiki/International_Atomic_Time > > [4] https://maia.usno.navy.mil/ser7/tai-utc.dat > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > >
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
