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 <ro...@rogerprice.org> wrote: > On Tue, 24 Aug 2021, Arnaud Quette wrote: > > > Le ven. 20 août 2021 à 17:38, Roger Price <ro...@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@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