plusTime with more than one "unit"

[chris2286266]

What would be a good implementation of a timeStamp for a rule like "birthDate + 12 years + 3 month + 1 day"?

Would it be something like "plusTime(4475, day)" (if we round leap years and month with different length). Or woud it be possible with nested plusTime statements, like "plusTime(plusTime(plusTime(birthDate, 12 year), 3 month), 1 day)"

Thanks

[dslmeinte]

The nested option is not possible, since the first argument to plusTime has to be a string with a date(-time). So, currently there's no way to add an amount of time to a date(-time) other than an integer number of years, months, or days.

To make it possible we could change CertLogic. I'm not so much in favour of allowing the nested use of plusTime because it'd make plusTime type-dependent (or polymorphic) in the first argument. I'm thinking of something like: `plusTime(birthDate, 12, "year", 3, "month", 1, "day"). So, instead of just a 2nd and 3rd argument containing an amount and time unit, optionally also 2i-nd, and (2i+1)-nd arguments containing amounts and time units. That'd also be more in the “spirit of JsonLogic”, it seems.

Would that work for your use case? (Mind: I still have to check what the impact on the implementation would be.)

[chris2286266]

Thanks Meinte!

The usecase is, that some "clever" politicians have formulated (AT-internal) rules like "For children starting at the age of 6 (1) years until the age of 12 years plus three month (2) ..." and another rule like "From the age of 12 years + 3 month until the end of compulsory schooling (3) ..."

(1) is clear "not-after": [ {"plusTime":[{payload.dob},6,"year"]}, {"plusTime":[{external.validationClock},0,"day"]}, ...

(2) this is the question, I think we will replace it by something like {"plusTime":[{payload.dob},147,"month"]},

(3) ... this is another topic ...

[dslmeinte]

Hi Chris,

If it makes sense for the epidemiologists, we'd better comply, I'd say.

My experience with such kinds of rules is that the ones making them usually haven't thought about what a sentence fragment like “plus three months” means exactly. Is it just advancing the calendar months, or advancing by 30 days (as e.g. it would be in Dutch income tax law), etc.? You might want to clear this up with the policy makers, and possibly “guide” the questions a bit towards what makes sense technologically as well.

In CertLogic “date(-time) plus n tu” means advancing that date(-time) with n units of tu keeping the time zone offset of date(-time). This is equivalent to e.g. in JavaScript dateTime.setUTC<Tu>(dateTime.getUTC<Tu>() + _n_).

For case 2, adding 147 months seems to do what you need it to do. You might want to check (e.g. using https://certlogic-fiddle.vercel.app/) whether this produces offsets for leap years, but I actually don't think so.

I don't see a “... + 1 day” use case in your 2nd post anymore. Can you check/test whether you'd still need it? If not, is the “... + 147 months” “trick” enough?

This is for AT-internal/domestic DCC validation, right? That means that we could add it to CertLogic without every verifier needing to upgrade to this version (of both spec and implementation). At the same time, I don't mind keeping CertLogic as stable as possible.

[dslmeinte]

Just checked: https://certlogic-fiddle.vercel.app/?expr=%7B%0A++%22plusTime%22%3A+%5B+%222022-01-01%22%2C+147%2C+%22month%22+%5D%0A%7D&data=%7B%7D Conclusion: “... + 147 months” doesn't produce offsets due to leap years (or seconds). I expect that's what you need, anyway.

[chris2286266]

I agree about "policy makers" ;-)

I got some details in the meantime, so I know: In the case "+ 3 month" they mean "advance the month". The "+ 1 day" can be substitued with the "after" vs. "not-before" behaviour (> vs. >=). The "6 or 12 years" is the same: Add calender years (and not 365 days * year), so leap years can be ignored. But I will chech in certlogic-fiddle though.

I don't think a special engine version would make sense for just this topic ...

[chris2286266]

Ups ... just saw your comment concerning fiddle ... thanks.