-
Notifications
You must be signed in to change notification settings - Fork 266
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use milliseconds formats in dates not related with DateTime #3671
Comments
Upon completion of this issue, review repo content (especially documentation) looking for |
Maybe #3989 (comment) supports the need of using milliseconds for lastNotification/lastSuccess/lastFailed... |
As per my understanding of this issue we need to change |
Changes in the documentation are the final part of this issue. The first part is to implement milliseconds support for lastNotification, lastFailure and lastSuccess. |
PR #3668 implements milliseconds support for DateTime attributes and metadata. However, Orion uses ISO8601 dates in other places, in particular:
Currently, they are managed as seconds and rendered using the
.00Z
format.First question is if they should support milliseconds. For expiration dates, seconds precision is fine. For last* fields, network will introduce some "distortion" in the form of small delays, so we probably we don't need high precision here.
However, even in the case we keep seconds precision for these fields, I think we should use the
.000Z
when rendering them. It is a bit weird to use three decimals in some renderings (DateTime values and metadata) but two decimals in other places.The text was updated successfully, but these errors were encountered: