Hi Eliot,

thanks for the answer. From what you wrote I assume that your explanation is based on RFC 3339 but I could not find this behavior specified there, only a note (second bullet) <https://www.rfc-editor.org/rfc/rfc3339#section-1> that the exact situation we are discussing is not considered.

In any case, adding a sentence mentioning this situation in the type description may be useful to ensure the canonical value is unambiguous. Not sure if errata would be acceptable or it can be added only once some updated YANG module is being defined (if that happens).

Regards,
Michal

On 24. 4. 2023 14:48, Eliot Lear wrote:

Hi,

Hiya,

On 24.04.23 14:20, Michal Vasko wrote:
Hi,

I would like to have a specific date-and-time canonical value clarified because I am not sure what exactly is expected. If a system is using NZST (+12:00, New Zealand Standard Time) and is printing the timestamp 2023-02-23T10:00:00+12:00, should the output be

1. 2023-02-23T10:00:00+12:00 because the system is currently in NZST or
2. 2023-02-23T11:00:00+13:00 because at the time of the timestamp the system was in NZDT (+13:00)?

It is not clear to me from the ietf-yang-types:date-and-time description and I have observed that localtime(3) adjusts the timezone according to the timestamp meaning if I followed the same logic, I would use 2.

RFC 3339 governs, and it's a simple rule: if the local offset at the time is +12, use +12.  If the local offset at the time is +13, use +13.  At the time, according to the normal time zone rules, it should have been +13.  But what matters more is what the device thought the offset was *at the time*.  So if it wrongly thought the offset was +12, then that is what should be in the timestamp.

% TZ=Pacific/Auckland date -j 022311002023
Thu Feb 23 11:00:00 *NZDT* 2023.
% TZ=Pacific/Auckland date -j -Iseconds 022311002023

2023-02-23T11:00:00+*13:00*

Eliot

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to