[Nut-upsuser] RFC - Propose to express dates using ISO 8601 when possible

[Roger Price]

On Tue, 24 Aug 2021, Arnaud Quette wrote:

> Le ven. 20 août 2021 à 17:38, Roger Price <roger at rogerprice.org> a écrit :
>       On Fri, 20 Aug 2021, Jim Klimov via Nut-upsuser wrote:
>
>       > It is a bit unclear what "or otherwise and Combined date and time
>       > representations" means. An example of ISO 8601 date representation (one of
>       > many offered by the standard) "or otherwise"? Which combined date and time
>       > would we take - e.g. YYYYMMDDTHHMMSSZ (literal T separator and Z for "zulu"
>       > UTC timezone)? Or with dashes and colons? Or...?
>
>       Since we are concerned only with dates, and not time of day, things are a little
>       simpler.  We follow ISO 8601 clause 5.2.1 Calendar dates, and we don't have to
>       worry about timezones.  The only real choice is between the format YYYYMMDD and
>       YYYY-MM-DD.  Since our dates are intended primarily for humans it seems better
>       to use the format YYYY-MM-DD which has better readability.  It's always possible
>       to extract the YYYYMMDD number if this is eventually needed.
>
>       Roger
>
>       See also RFC 3339 "Date and Time on the Internet: Timestamps"
> 
>  Hi guys,
> 
> sorry, I completely missed your mail answers, and only focused on the PR comments.
> So thanks for your feedback.
> 
> My original intent was only focused on the battery.date{,.maintenance}. 
> However, I thought to myself that it could be broadened to all .date 
> (including ups*). As mentioned, it's an option. Opaque string format still 
> applies, and *if possible*, ISO 8601 Calendar date should be used.

> As for the time, I'm still in between: for the base date variables, it's only 
> date without time. There is even a ups.time to track the device clock. So even 
> if I amended the PR to include a variation of <date>T<time>, I can revert it 
> if you prefer.

I had forgotten about ups.time.  Should date and time in NUT be exclusively 
opaque, human-readable? Perhaps the safest strategy for the long term is to 
follow RFC 3339.  This has advantages over ISO 8601:

  * Available without charge to everybody.
  * Includes in appendix A grammars for date, time, duration and period.

Roger