Re: [Nut-upsuser] RFC - Propose to express dates using ISO 8601 when possible
On Sun, 19 Sep 2021, Jim Klimov wrote: 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? Hello Jim, If we have examples of what NUT should do in the cases NUT meets, and they satisfy both RFC 3339 and ISO 8601 then that would be perfect. Roger PS: Its RFC 3339 and not RFC 3389. My error. PS2: The ISO now charge CHF 158 for ISO 8601 part 1 and CHF 178 for part 2.___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] RFC - Propose to express dates using ISO 8601 when possible
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 wrote:
> On Tue, 24 Aug 2021, Arnaud Quette wrote:
>
> > Le ven. 20 août 2021 à 17:38, Roger Price 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. MMDDTHHMMSSZ (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
> MMDD and
> > -MM-DD. Since our dates are intended primarily for humans it
> seems better
> > to use the format -MM-DD which has better readability. It's
> always possible
> > to extract the MMDD 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 T, 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@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] RFC - Propose to express dates using ISO 8601 when possible
On Tue, 24 Aug 2021, Arnaud Quette wrote:
Le ven. 20 août 2021 à 17:38, Roger Price 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. MMDDTHHMMSSZ (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
MMDD and
-MM-DD. Since our dates are intended primarily for humans it seems
better
to use the format -MM-DD which has better readability. It's always
possible
to extract the MMDD 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 T, 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@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] RFC - Propose to express dates using ISO 8601 when possible
Le ven. 20 août 2021 à 17:38, Roger Price 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. MMDDTHHMMSSZ (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
> MMDD and
> -MM-DD. Since our dates are intended primarily for humans it seems
> better
> to use the format -MM-DD which has better readability. It's always
> possible
> to extract the MMDD 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 T, I can
revert it if you prefer.
Thanks and cheers,
Arno
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] 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. MMDDTHHMMSSZ (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 MMDD and -MM-DD. Since our dates are intended primarily for humans it seems better to use the format -MM-DD which has better readability. It's always possible to extract the MMDD number if this is eventually needed. Roger See also RFC 3339 "Date and Time on the Internet: Timestamps" ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] RFC - Propose to express dates using ISO 8601 when possible
Dittoing what I wrote in PR comments: 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. MMDDTHHMMSSZ (literal T separator and Z for "zulu" UTC timezone)? Or with dashes and colons? Or...? Otherwise, as a generally uniform and standardized approach - LGTM :) On Fri, Aug 20, 2021, 14:10 Arnaud Quette via Nut-upsuser < nut-upsuser@alioth-lists.debian.net> wrote: > Hi all, > > I've made a pull request in that sense: > https://github.com/networkupstools/nut/pull/1076 > > I'll follow-up with applying to some drivers and propose more PRs. > > As usual, comments and feedback welcome. > > cheers, > Arno > ___ > Nut-upsuser mailing list > Nut-upsuser@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] RFC - Propose to express dates using ISO 8601 when possible
Hello, On 20.08.21 15:01, Roger Price wrote: Will this apply to variables | ups.date | Internal UPS clock date | ups.mfr.date | UPS manufacturing date | ups.test.date | Date of last self test | battery.date | Battery change date (opaque string) | 11/14/00 | battery.mfr.date | Battery manufacturing date which will no longer be opaque strings? Roger FYI: this mail has been catched by my spamfilter because .date string was evaluated as suspicious TLD. I don't think it's NUT's issue or something NUT should care about but it might affect you as long. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. A day without sunshine is like, night. ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] RFC - Propose to express dates using ISO 8601 when possible
On Fri, 20 Aug 2021, Arnaud Quette via Nut-upsuser wrote: Hi all, I've made a pull request in that sense: https://github.com/networkupstools/nut/pull/1076 I'll follow-up with applying to some drivers and propose more PRs. As usual, comments and feedback welcome. Will this apply to variables | ups.date | Internal UPS clock date | ups.mfr.date | UPS manufacturing date | ups.test.date | Date of last self test | battery.date | Battery change date (opaque string) | 11/14/00 | battery.mfr.date | Battery manufacturing date which will no longer be opaque strings? Roger ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
