Dates and Time in JsonLogic: best practices.

[tavrelkate]

Hi everyone,

I haven’t found a concise guide on website for handling dates/time calculation in JsonLogic and would love to sanity-check the approach.

A common business check example: “User is over 21., it's age > 21 years”

{
  "<": [
    { "var": "user.birthday_iso.answer" },
    { "var": "time.minus_21y_iso" }
  ]
}

Where time.minus_21y_iso is computed upstream as “now - 21 calendar years” and all dates are YYYY-MM-DD (UTC, day precision).

This works, but it adds ceremony because core JsonLogic lacks date/time operators. In practice we have to push precomputed values (e.g., time.minus_21y_iso) into the data just to express ‘minus 21 year’ or force to write custom date/time operators. I believe many users expect first-class support for routine date checks when they choose a production-ready DSL for rules (JsonLogic).

First Step

Before going into details I just want to gauge interest: Is there interest in standardizing a minimal approach?

If there’s willingness to move in either direction, I’m happy to help shape a concrete proposal.

Prior threads / references

• Date and time handling (core repo): Date and time handling jwadhams/json-logic#27

• [Feature] support dates (json-logic-js): [Feature] support dates jwadhams/json-logic-js#6

• Official ops (no date ops in core): https://jsonlogic.com/operations.html

Thanks!

[TotalTechGeek]

Hey there!

Some Flavor

Wanted to add a bit of context early on; (this does not dispute what's being communicated).

For comparison operators, we've had some discussion over here: https://github.com/orgs/json-logic/discussions/23#discussioncomment-12111210
Which pairs somewhat with: https://github.com/orgs/json-logic/discussions/17

Essentially, while we encourage JSON Logic implementations to support language idiomatic constructs (Infinity, Date, Map, etc), any Core operators or community extensions need to be designed around JSON constructs for maximum compatibility & portability.

Time

We've had some side discussions about time in the past on the CNCF Slack,

My thoughts are:

• Time should be our first community extension, and would be quickly introduced to our recommended baseline for implementations. (We might want to leave it out of core to avoid exploding the scope of the formal specification).
• I think we should avoid adding any non-deterministic operators to Core / main community extensions, so that logic is relatively predictable and easily testable.

For example, instead of introducing { now: [] } as an operator, we should recommend folks pass now in as a value into context ({ val: 'now' }. This pattern should be much more reliable in practice & allow them to queue up operations / reproduce the execution quite easily.

I would also recommend we take a look at something like date-fns and pick a handful of operators from there.

Operators we would probably consider:

• addX (addDays, addHours, addSeconds, etc) - We could decide whether it's composite like add(now, 5, 'minutes') or addMinutes(now, 5)
• differenceInX - differenceInDays(@.now, @.before)
• fromISO8601
• toISO8601
• formatTime
• isBefore / isAfter
• startOfX / endOfX

I think the operators should support both numbers (defined as unix time in ms) and ISO8601.

[TotalTechGeek]

And to clarify 😄 , certain community extensions may be enabled by default (like time), as we can fold it into a recommended baseline for JSON Logic implementations.

[codetiger]

In my Rust library datalogic-rs I've implemented datetime and timestamp related operators

Test cases are available here
https://github.com/GoPlasmatic/datalogic-rs/tree/main/tests/suites/datetime

[tavrelkate]

Great, thanks for sharing it @codetiger, I will take a look at it.

[TotalTechGeek]

Here's how I've generally structured it in the past on my side:

time.isAfter(@.now, time.addYears(@.user.birthday, 21)) ->

{
  'time.isAfter': [
    {
      val: 'now'
    },
    {
      'time.addYears': [
        {
          val: [
            'user',
            'birthday'
          ]
        },
        21
      ]
    }
  ]
}

Where @.now and @.user.birthday can work regardless of whether they're a native Date, number (milliseconds since unix epoch), or ISO8601 string.

My general preference would be that the time functions have a standard return type that can be represented in JSON Logic portably, and I think it should probably use unix time to represent dates in the returns.

Similarly, you could express:

`Deadline: {time.format(time.endOfMonth(@.now), 'YYYY-MM-dd')}`

With

{
  cat: [
    'Deadline: ',
    {
      'time.format': [
        {
          'time.endOfMonth': {
            val: 'now'
          }
        },
        'YYYY-MM-dd'
      ]
    }
  ]
}

[codetiger]

In my implementation, the datetime operator converts string in ISO 8601 format with optional timezone offset into datetime datatype internally. Then all arithmetic and comparison operators support operations on datetime and other datatype whereever applicable.

https://goplasmatic.github.io/datalogic-rs/operators/datetime.html