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]
