Make datetime extension an experimental feature

[shaobo-he-aws]

Description of changes

Issue #, if available

Checklist for requesting a review

The change in this PR is (choose one, and delete the other options):

• A backwards-compatible change requiring a minor version bump to cedar-policy (e.g., addition of a new API).

I confirm that this PR (choose one, and delete the other options):

• Updates the "Unreleased" section of the CHANGELOG with a description of my change (required for major/minor version bumps).

I confirm that cedar-spec (choose one, and delete the other options):

• Does not require updates because my change does not impact the Cedar formal model or DRT infrastructure.

I confirm that docs.cedarpolicy.com (choose one, and delete the other options):

• Requires updates, and I have made / will make these updates myself. (Please include in your description a timeline or link to the relevant PR in cedar-docs. PRs should be targeted at a staging-X.Y branch, not main.)

[john-h-kastner-aws]

Why did you undo the change to remove datetime as a default feature in the core and validator crates? I would think that's what we want

[shaobo-he-aws]

Why did you undo the change to remove datetime as a default feature in the core and validator crates? I would think that's what we want

I thought that we an experimental feature is meant to apply to cedar-policy since it contains public APIs. Do you think that we should provide the same guarantee in core and validator (i.e., default features should be DRTed) as well?

[john-h-kastner-aws]

Do you think that we should provide the same guarantee in core and validator (i.e., default features should be DRTed) as well?

This is more a question about how Cargo will handle this feature. If datetime is default in cedar-policy-core, and cedar-policy depends on it without no-default-features, then I would expect that the datetime extension would be enabled when parsing Cedar policies even when it's not explicitly enabled by the consumer of cedar-policy

[shaobo-he-aws]

This is more a question about how Cargo will handle this feature. If datetime is default in cedar-policy-core, and cedar-policy depends on it without no-default-features, then I would expect that the datetime extension would be enabled when parsing Cedar policies even when it's not explicitly enabled by the consumer of cedar-policy

I see. It makes sense. I'll revert the latest commit.