<div dir="auto">Hello all,<div dir="auto"><br></div><div dir="auto">  Roger's point about ISO vs. RFC "original" spec accessibility sounds valid, since most of the ISO 8601 descriptions I've seen were re-tells - in wiki, date-parsing tools/libs docs, etc. Used it for years and did not realize :)</div><div dir="auto"><br></div><div dir="auto">  I revised and logged some thoughts at <a href="https://github.com/networkupstools/nut/pull/1076">https://github.com/networkupstools/nut/pull/1076</a> and intend to clarify this in our text like "time/date representations that satisfy both RFC 3389 and ISO 8601 standards, following these examples: ..." -- would this be reasonable, Roger?</div><div dir="auto"><br></div><div dir="auto">Jim</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 25, 2021, 10:15 Roger Price <<a href="mailto:roger@rogerprice.org">roger@rogerprice.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 24 Aug 2021, Arnaud Quette wrote:<br>
<br>
> Le ven. 20 août 2021 à 17:38, Roger Price <<a href="mailto:roger@rogerprice.org" target="_blank" rel="noreferrer">roger@rogerprice.org</a>> a écrit :<br>
>       On Fri, 20 Aug 2021, Jim Klimov via Nut-upsuser wrote:<br>
><br>
>       > It is a bit unclear what "or otherwise and Combined date and time<br>
>       > representations" means. An example of ISO 8601 date representation (one of<br>
>       > many offered by the standard) "or otherwise"? Which combined date and time<br>
>       > would we take - e.g. YYYYMMDDTHHMMSSZ (literal T separator and Z for "zulu"<br>
>       > UTC timezone)? Or with dashes and colons? Or...?<br>
><br>
>       Since we are concerned only with dates, and not time of day, things are a little<br>
>       simpler.  We follow ISO 8601 clause 5.2.1 Calendar dates, and we don't have to<br>
>       worry about timezones.  The only real choice is between the format YYYYMMDD and<br>
>       YYYY-MM-DD.  Since our dates are intended primarily for humans it seems better<br>
>       to use the format YYYY-MM-DD which has better readability.  It's always possible<br>
>       to extract the YYYYMMDD number if this is eventually needed.<br>
><br>
>       Roger<br>
><br>
>       See also RFC 3339 "Date and Time on the Internet: Timestamps"<br>
> <br>
>  Hi guys,<br>
> <br>
> sorry, I completely missed your mail answers, and only focused on the PR comments.<br>
> So thanks for your feedback.<br>
> <br>
> My original intent was only focused on the battery.date{,.maintenance}. <br>
> However, I thought to myself that it could be broadened to all .date <br>
> (including ups*). As mentioned, it's an option. Opaque string format still <br>
> applies, and *if possible*, ISO 8601 Calendar date should be used.<br>
<br>
> As for the time, I'm still in between: for the base date variables, it's only <br>
> date without time. There is even a ups.time to track the device clock. So even <br>
> if I amended the PR to include a variation of <date>T<time>, I can revert it <br>
> if you prefer.<br>
<br>
I had forgotten about ups.time.  Should date and time in NUT be exclusively <br>
opaque, human-readable? Perhaps the safest strategy for the long term is to <br>
follow RFC 3339.  This has advantages over ISO 8601:<br>
<br>
  * Available without charge to everybody.<br>
  * Includes in appendix A grammars for date, time, duration and period.<br>
<br>
Roger_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank" rel="noreferrer">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div>