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

[Jim Klimov]

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>