On Thu, Oct 08, 2026 at 09:14:23AM +0200, David Kalnischkies wrote: > Hi, > > that is an interesting find! > (And some sad code) > > Am Wed, Oct 07, 2026 at 11:47:19PM -0600, schrieb Christian Noé Ramos López: > > Two things would avoid it: computing the date with a calendar, or > > passing "+1y", which sqv accepts as an offset (--policy-as-of +1y > > exits 0 here). > > The former should be relatively easy (as far as dates are concerned) > with what is available via <chrono> in C++20 and above (nowadays). > > > The second option seems (at least for now) to be a usage error itself > as the documentation (sqv manpage) for --policy-as-of says > | The time is expressed as an ISO 8601 formatted timestamp. > > And earlier it expressed in general: > | The TIMESTAMPs must be given in ISO 8601 format > > I presume that +1y works stems from --time which says: > | Set the reference time as an ISO 8601 formatted timestamp or > | relative offset. […] This time is also used as the default > | value for --not-after and --policy-as-of […] > > "relative offset" does not seem defined through. > > Aside: I /suppose/ "PY1" would be a valid ISO 8601 (duration), > but I haven't dared to try how sqv would react. > > > Maybe its just me, but I would prefer the former (even if documentation > of sqv is changed) as the wording --policy-as-of highly suggests an > exact date for me… even if I realize as of 5 seconds later that this > might be a valid way of speaking, too.
Yes we actually want to use midnight here. I'm not sure if the best approach is to the the 1 year from now or to truncate the day field until it produces a valid date, such that 02-29 truncates to 02-28 rather than extends to 03-01 (semantically preserving the end of month). I guess it's easier though to do the chrono change and perhaps that's what we should do yeah. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
