feat: add $flagd.timestamp to json evaluator

[craigpastro]

This PR

Adds "timestamp" to the json evaluation context.

Related Issues

Related to #851. I am not sure we want to say that it closes the issue though.

[netlify]

✅ Deploy Preview for polite-licorice-3db33c canceled.

Name	Link
🔨 Latest commit	c3a3cf4
🔍 Latest deploy log	https://app.netlify.com/sites/polite-licorice-3db33c/deploys/6526a5bd7f14b40008aa1898

[codecov]

Codecov Report

Merging #958 (c3a3cf4) into main (fee1558) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #958   +/-   ##
=======================================
  Coverage   72.62%   72.63%           
=======================================
  Files          28       28           
  Lines        2857     2858    +1     
=======================================
+ Hits         2075     2076    +1     
  Misses        685      685           
  Partials       97       97           

Files	Coverage Δ
core/pkg/eval/json_evaluator.go	84.74% <100.00%> (+0.05%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[toddbaert]

Makes sense to me! Thanks!

@Kavindu-Dodan @bacherfl @beeme1mr @thisthat what do you think about this implementation? And about my points here?

I think this is a nice feature, because it can allow for a really simple "timed rollout", especially when combined with the fractional operation.

[Kavindu-Dodan]

Makes sense to me! Thanks!

@Kavindu-Dodan @bacherfl @beeme1mr @thisthat what do you think about this implementation? And about my points here?

I think this is a nice feature, because it can allow for a really simple "timed rollout", especially when combined with the fractional operation.

Timed rollouts are an interesting feature. Besides, this can be used combined with other json logic operators to enable flag in time range.

[beeme1mr]

Love it, thanks!

As a follow up, can you update the following docs to include information on these flagd properties?

• https://github.com/open-feature/flagd/blob/main/docs/reference/flag-definitions.md
• https://github.com/open-feature/flagd/blob/main/docs/reference/specifications/in-process-providers.md

In the flag definitions file, adding a section right before Shared evaluators makes sense. It can include a short description that explains that these properties are automagically included in the context. Below that could be a table listing the properties, the version they were introduced, and a short description.

The in-process spec should also include a section that lists flagd properties as a requirement and what their expected behavior is.

[toddbaert]

Love it, thanks!

As a follow up, can you update the following docs to include information on these flagd properties?

• https://github.com/open-feature/flagd/blob/main/docs/reference/flag-definitions.md
• https://github.com/open-feature/flagd/blob/main/docs/reference/specifications/in-process-providers.md

In the flag definitions file, adding a section right before Shared evaluators makes sense. It can include a short description that explains that these properties are automagically included in the context. Below that could be a table listing the properties, the version they were introduced, and a short description.

The in-process spec should also include a section that lists flagd properties as a requirement and what their expected behavior is.

Agreed on all counts. I didn't want to do this until everyone agreed on this approach, but since it's clear we all do I'll do documentation next (or create an issue for it).