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. 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