On the date: the chrono computation sounds right to me too, and I have no preference between truncating 02-29 to 02-28 and extending it.
One thing that outlives whichever lands. In my rows sqv exits 1 when the policy rejects a signature and 2 on a usage error, and the year-ahead pass does not separate them -- both arrive as a policy rejection and warn on every repository. The leap day is one way to reach exit 2 there; any other usage-level failure in that pass would look the same. Is separating them worth doing? Christian Ramos Norte Software [email protected] El lun, 12 oct 2026 a la(s) 1:15 p.m., Julian Andres Klode ([email protected]) escribió: > > 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 -- Christian Ramos Director general · Norte Software [email protected] +52 9671456444 nortesoftware.dev SAN CRISTÓBAL DE LAS CASAS · CHIAPAS
