DateTimeImmutable parses time-fractions wrongly

[heiglandreas]

Description

The following code:

<?php

$validDateTimeStringsAccordingToIso8601 = [
    '20230328T070000.000Z',     // a basic format containing a millisecond fraction
    '2023-03-28T07:00:00.000Z', // The exact same as extended format
    '20230328T07.5Z'            // a basic format describing 7:30 according to ISO
    ];
    
foreach ($validDateTimeStringsAccordingToIso8601 as $dateTime) {
    try {
        $d = new DateTimeImmutable($dateTime);
        echo $d->format('c') . PHP_EOL;
    } catch (Throwable $t) {
        echo $t . PHP_EOL;
    }
}

Resulted in this output:

Exception: Failed to parse time string (20230328T070000.000Z) at position 16 (0): Unexpected character in /in/ZJt06:11
Stack trace:
#0 /in/ZJt06(11): DateTimeImmutable->__construct('20230328T070000...')
#1 {main}
2023-03-28T07:00:00+00:00
2023-03-28T07:05:00+00:00

But I expected this output instead:

2023-03-28T07:00:00+00:00
2023-03-28T07:00:00+00:00
2023-03-28T07:30:00+00:00

(See also https://3v4l.org/ZJt06)

There seems to be an issue with the interpretation of fractions when parsing datetime-strings. According to ISO the above mentioned strings are all valid and should be parseable. Especially as the first and the second example are the same datetime in a different notation they should be interpreted similarily.

A decimal fraction may be added to the lowest order time element present in any of these representations. A decimal mark, either a comma or a dot, is used as a separator between the time element and its fraction. (Following ISO 80000-1 according to ISO 8601:1-2019,[26] it does not stipulate a preference except within International Standards, but with a preference for a comma according to ISO 8601:2004.[27]) For example, to denote "14 hours, 30 and one half minutes", do not include a seconds figure; represent it as "14:30,5", "T1430,5", "14:30.5", or "T1430.5".

There is no limit on the number of decimal places for the decimal fraction. However, the number of decimal places needs to be agreed to by the communicating parties. For example, in Microsoft SQL Server, the precision of a decimal fraction is 3 for a DATETIME, i.e., "yyyy-mm-ddThh:mm:ss[.mmm]".[28]

(https://en.wikipedia.org/wiki/ISO_8601#Times)

I'd argue about the third but as it is specified in the ISO explicitly I'd also expect that to work.

PHP Version

PHP 8.1 and 8.2

Operating System

No response

[heiglandreas]

As https://www.php.net/manual/en/datetime.formats.compound.php mentiones fractions of a second as possibility while parsing a datetime-string and one string parses them while the other doesn't seems to be at least an inconsistency.

[derickr]

First of all, there is a misconception that the DateTimeImmutable() constructor implements the full ISO8601 standard. The documented formats mentions no such thing.

Currently, timelib does correctly parse the non-compressed format (2022-06-02T16:58:35.698), but the documentation also does not include the compressed or extended time format with milli- or micro-seconds.

timelib never implemented fractional time units (for hour, minutes, and second), and does not claim to do so.

It is probably possible to implement parsing all ISO 8601 strings, but I am going to suspect that that could break some of the other already existing intricate parsing rules. Therefore, it might be better to add a dedicated (factory) method for this instead.

I am closing this as "Invalid" (as it matches the documentation, and everything is intentional), but am open to discuss a new feature request to add full ISO 8601 string parsing.

[heiglandreas]

I was indeed yesterday thinking about a factory that would handle ISO string parsing. I don't think that needs to be handled in C though. I'm pretty sure that could also be handled in userland even though C might be a tad faster.