[Yaml] Allow dumping DateTimeInterface objects with milliseconds or microseconds

[dustinwilson]

Description

At present the Yaml component will parse date formats such as 2023-01-08T16:18:25.213Z but it can't dump them, instead only using the 'c' format which doesn't contain milliseconds. I would like to suggest having Inline use 'Y-m-d\TH:i:s.vO' and 'Y-m-d\TH:i:s.uO' instead when the DateTimeInterface object being dumped contains milliseconds or microseconds respectively. It wouldn't require any additional flags but instead have it intelligently choose which format to output based on how precise the DateTimeInterface is.

Example

Currently

In:

date: 2023-01-08T16:18:25Z
date_with_milliseconds: 2023-01-08T16:18:25.213Z
date_with_microseconds: 2023-01-08T16:18:25.718800Z

Out:

date: 2023-01-08T16:18:25+00:00
date_with_milliseconds: 2023-01-08T16:18:25+00:00
date_with_microseconds: 2023-01-08T16:18:25+00:00

Suggested

In:

date: 2023-01-08T16:18:25Z
date_with_milliseconds: 2023-01-08T16:18:25.213Z
date_with_microseconds: 2023-01-08T16:18:25.718800Z

Out:

date: 2023-01-08T16:18:25+00:00
date_with_milliseconds: 2023-01-08T16:18:25.213+00:00
date_with_microseconds: 2023-01-08T16:18:25.718800+00:00

[alamirault]

I think configuring datetime dump format could be great, but it is maybe not easy with bitmask implementation 🤔

[dustinwilson]

It wouldn't need any settings:

I would like to suggest having Inline use 'Y-m-d\TH:i:s.vO' and 'Y-m-d\TH:i:s.uO' instead when the DateTimeInterface object being dumped contains milliseconds or microseconds respectively. It wouldn't require any additional flags but instead have it intelligently choose which format to output based on how precise the DateTimeInterface is.

If the DateTimeInterface has millisecond precision it would output milliseconds in the yaml file. If it has microseconds it would output microsecond precision. The way it is currently there is potential data loss when writing to a yaml file.

There's probably a better way to do this, but this was the first idea that came to mind right now:

function getFormat($date) {
    $test = rtrim($date->format('u'), '0');
    if ($test === '') {
        return 'c';
    } elseif (strlen($test) < 4) {
        return 'Y-m-d\TH:i:s.vP';
    }
    return 'Y-m-d\TH:i:s.uP';
}

echo getFormat(new \DateTime('2023-01-09T01:02:03Z')) . "\n";
echo getFormat(new \DateTime('2023-01-09T01:02:03.4Z')) . "\n";
echo getFormat(new \DateTime('2023-01-09T01:02:03.456Z')) . "\n";
echo getFormat(new \DateTime('2023-01-09T01:02:03.4567Z')) . "\n";
echo getFormat(new \DateTime('2023-01-09T01:02:03.456789Z')) . "\n";

Result:

c
Y-m-d\TH:i:s.vP
Y-m-d\TH:i:s.vP
Y-m-d\TH:i:s.uP
Y-m-d\TH:i:s.uP

[dustinwilson]

I started work on a pull request for this and had everything just about ready to go. But, I realized that something would also need to be done about parsing dates when not using Yaml::PARSE_DATETIME. This part would be a breaking change, though. It'd either change the type of what is output from the parser or have it need to be a much bigger number.

For instance when parsing 2023-01-09T01:02:03.4567Z it would need to be parsed as either 1673226123.4567 or 1673226123456700.

[stof]

I suggest parsing it as 1673226123.4567. Parsing it as 1673226123456700 would be totally unusable as the "unit" of the timestamp would be different for different decimals.