Deprecation for YAML datetime parsing

[jborean93]

SUMMARY

Add deprecation for having YAML parse plain YAML scalar values as a datetime object. This is to avoid ambiguity in how the final parsed value is formatted as a string when used.

It does not seem like PyYAML exposes a way to determine if the Node value was explicitly tagged or not at the point where the deprecation warning is emitted. This means that we cannot preserve the existing behaviour if explicitly tagged rather than what the PR does which is deprecate all instances where the datetime logic is used.

Fixes: #80948

ISSUE TYPE

• Feature Pull Request

ADDITIONAL INFORMATION

The YAML 1.2 spec also removes the automatic datetime parsing of string so this is a nice way to eventually be compliant with that version.

[webknjaz]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[nitzmahone]

Thanks for playing with this!

We need to have a broader discussion about the ideal YAML tag set we'd like to support, including whether we'll warn (and eventually disable) any support for undesired tags/types or just implicit tag resolution (probably also in the context of YAML 1.2). Once we've got our overall direction, we can set deprecation warnings accordingly (including warn-only-on-touch behaviors with data tagging if we want). Pending the outcome of that discussion, the parser layer knows if a tag was implicit/explicit- that info is currently discarded during the compose phase, but IIRC the API calls needed to smuggle it out on the post-resolved node objects that run through the constructors are all public and supported, so if we need to know the distinction in the constructor, we can.