On Mon, Apr 24, 2023 at 7:48 AM Carsten Bormann <c...@tzi.org> wrote:
> On 2023-04-24, at 14:20, Michal Vasko <mva...@cesnet.cz> wrote:
> >
> > canonical
>
> Hi Michal,
>
> I don’t know what exactly “canonical” means here.
>
>From the date-and-time typedef:
The canonical format for date-and-time values with a known time
zone uses a numeric time zone offset that is calculated using
the device's configured known offset to UTC time. A change of
the device's offset to UTC time will cause date-and-time values
to change accordingly. Such changes might happen periodically
in case a server follows automatically daylight saving time
(DST) time zone offset changes. The canonical format for
date-and-time values with an unknown time zone (usually
referring to the notion of local time) uses the time-offset
-00:00, i.e., date-and-time values must be reported in UTC.";
>
> As a general rule, timestamps used by machines should not use timezones,
> so you should use
>
> 2023-02-22T22:00:00Z
>
Yes -- this is what a NETCONF server is supposed to do I think.
I am not sure how the timezone would be known to the client or configured
on the server.
The server should always store and send date-and-time values in the 'Z'
format.
IMO, even if there is a "configured known offset to UTC time."
Andy
> If there is a use for indicating the timezone offset a particular system
> was in when the timestamp actually occurred, then you might indicate that
> with a timezone offset:
>
> 2023-02-23T11:00:00+13:00
>
> The point in time at which you formatted this datetime is never relevant.
>
> I’m having a hard time imagining when you want to supply this hint at an
> individual timestamp level — I would believe these all should be without
> timezone offsets, i.e., Z.
> Your system information might usefully have timezone information (see also
> below), if timezone is at all relevant to your system.
>
>
> Note that if you have additional information (“hints”) that you want to
> send with the actual timestamp, you probably want to know about SEDATE’s
> IXDTF:
>
> https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-07.html
>
> I don’t know when YANG will pick this up; I don’t know how important these
> hints are in management information (and that my uncertainty applies to
> using the timezone offset defined by RFC 3339 in YANG as well).
>
> Grüße, Carsten
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
