Nut upsuser - Aug 2021 - RFC - Propose to express dates using ISO 8601 when possible

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"

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.

Thanks and cheers,
Arno
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20210824/06ef74d5/attachment.htm>