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

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>

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

Hello all,

  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 :)

  I revised and logged some thoughts at
https://github.com/networkupstools/nut/pull/1076 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?

Jim

On Wed, Aug 25, 2021, 10:15 Roger Price <roger at rogerprice.org> wrote:
> 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_______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20210919/f35d126b/attachment.htm>