On 24/04/19 08:22 +0200, Ulrich Windl wrote: > I know that April 1st is gone, but maybe should be have "user-friendly > durations" also? Maybe like: > "a deep breath", meaning "30 seconds" > "a guru meditation", meaning "5 minutes" > "a coffee break", meaning "15 minutes" > "a lunch break", meaning "half an hour" > ... > > Typical maintenance tasks can be finished within guro meditation or coffee > breaks; only few require lunch breaks or more... ;-)
Hehe, and be aware that pacemaker already started the tradition of pioneering some innovative time expresssions, so don't say it too loudly: $ iso8601 -d epoch > Date: 1970-01-01 00:00:00Z Mostly as a follow-up for the above joke, please don't _ever_ refer to "epoch" as a date/time expression, it may go away any time without notice (or on relatively short notice, for being undue here). >>>> Jan Pokorný <jpoko...@redhat.com> schrieb am 24.04.2019 um 02:01 >>>> in Nachricht <20190424000144.ga23...@redhat.com>: >> On 16/04/19 12:38 ‑0500, Ken Gaillot wrote: >>> With just ‑r, it will tell you whether the specified rule from the >>> configuration is currently in effect. If you give ‑d, it will check as >>> of that date and time (ISO 8601 format). >> >> Uh, the date‑time data representations (encodings of the singular >> information) shall be used with some sort of considerations towards the >> use cases: >> >> 1. _data‑exchange friendly_, point‑of‑use‑context‑agnostic >> (yet timezone‑respecting if need be) representation >> ‑ this is something you want to have serialized in data >> to outlive the code (extrapolated: for exchange between >> various revisions of the same code) >> ‑ ISO 8601 fills the bill >> >> 2. _user‑friendly_, point‑of‑use‑context‑respecting representation >> ‑ this is something you want user to work with, be it the >> management tools or helpers like crm_rule >> ‑ ISO 8601 _barely_ fills the bill, fails in basic attampts of >> integration with surrounding system: >> >> $ CIB_file=cts/scheduler/date‑1.xml ./tools/crm_rule ‑c \ >> ‑r rule.auto‑2 ‑d "next Monday 12:00" >>> (crm_abort) error: crm_time_check: Triggered assert at >>> iso8601.c:1116: dt‑>days > 0 >>> (crm_abort) error: parse_date: Triggered assert at iso8601.c:757: >>> crm_time_check(dt) >> >> no good, let's try old good coreutils' `date` as the "chewer" >> >> $ CIB_file=cts/scheduler/date‑1.xml ./tools/crm_rule ‑c \ >> ‑r rule.auto‑2 ‑d "$(date ‑d "next Monday 12:00")" >>> (crm_abort) error: crm_time_check: Triggered assert at >>> iso8601.c:1116: dt‑>days > 0 >>> (crm_abort) error: parse_date: Triggered assert at iso8601.c:757: >>> crm_time_check(dt) > >> crm_time_check(dt) >> >> still no good, so after few more iterations: >> >> $ CIB_file=cts/scheduler/date‑1.xml ./tools/crm_rule ‑c \ >> ‑r rule.auto‑2 ‑d "$(date ‑Iminutes ‑d "next Monday 12:00")" >>> Rule rule.auto‑2 is still in effect >> >> that could be much more intuitive + locale‑driven (assuming users >> have the locales set per what's natural to them/what they are >> used to), couldn't it? >> >> I mean, at least allowing `‑d` switch in `crm_rule` to support >> LANG‑native date/time specification makes a lot of sense to me: >> https://github.com/ClusterLabs/pacemaker/pull/1756 FWIW. I now think we should leverage gnulib's parse-datetime module directly: https://github.com/ClusterLabs/pacemaker/pull/1756#issuecomment-486108864 -- Jan (Poki)
pgpPlgorxPO44.pgp
Description: PGP signature
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/