RFC 3339 Z suffix no longer works with date-time validation in 2.3

[oschwald]

Before 2.3, this code using \DateTime::RFC3339 accepted RFC 3339 timestamps with the Zulu (Z) suffix, e.g., 2014-04-12T23:20:50.052Z. As of 2.3, an exception with the message time must be a valid date/time in the format "2005-12-30T01:02:03+00:00" is thrown.

I previously mentioned this in a comment. I probably should have created a separate issue, but I didn't think much of it after initially testing out the pre-release version.

[henriquemoody]

Are you sure that it's working on version 2.2? I'm getting an exception when I runt the code below:

v::dateTime(\DateTime::RFC3339)->assert('2014-04-12T23:20:50.052Z')

[henriquemoody]

v::dateTime(\DateTime::RFC3339)->assert('2005-12-30T01:02:03+00:00')

This works fine on 2.3

[henriquemoody]

If you use PHP's DateTime constant as a format, you must check its value. See DateTimeInterface

RFC3339 = "Y-m-d\\TH:i:sP"
RFC3339_EXTENDED = "Y-m-d\\TH:i:s.vP"

It is possible to validate that the way you want, but you must use a different format: Y-m-d\TH:i:s.vp. It's very similar to RFC3339_EXTENDED, but it used p instead of P. You can check DateTime.format for more details.

I wouldn't like to overwrite PHP's default behaviour because that could cause more confusion. If I misunderstood your request, feel free to reopen the issue. I'm here to help!

Cheers 🐼

[oschwald]

Yes, this was working on 2.2. The tests for the above repo pass with 2.2 and fail with 2.3. We have weekly automated builds that were passing until last week. I also just tested this downgrading to 2.2.

DateTime can parse this fine:

echo  DateTime::createFromFormat(DateTime::RFC3339_EXTENDED, '2014-04-12T23:20:50.052Z')->format("H:i:s.v");

outputs 23:20:50.052.

[oschwald]

I bisected the issue to 5fe4b96.

[oschwald]

The issue is $value !== $formattedDate->format($format) as 2014-04-12T23:20:50.052Z will be turned into 2014-04-12T23:20:50.052+00:00.

[henriquemoody]

I wouldn't call this an "issue", although I understand that that can be problematic for your use case.

The commit you mentioned aimed to fix an issue with the date-related rules. See #1274.

Our date-related rules aim to respect the format that we pass to them. The value of DateTimeInterface::RFC3339 is Y-m-d\\TH:i:sP, while the input in your example matches the Y-m-d\TH:i:s.vp format.

[oschwald]

This is a breaking change. It accepted valid RFC 3339 timestamps before the change with the PHP RFC3339 format and now it rejects them.

…

On Fri, Feb 2, 2024, 3:27 AM Henrique Moody ***@***.***> wrote: I wouldn't call this an "issue", although I understand that that can be problematic for your use case. The commit you mentioned aimed to fix an issue with the date-related rules. See #1274 <#1274>. The date-related aim is to respect the format that we pass to them. The value of DateTimeInterface::RFC3339 is Y-m-d\\TH:i:sP, while the input in your example matches the Y-m-d\TH:i:s.vp format. — Reply to this email directly, view it on GitHub <#1442 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACECMYKAIIEPK3NBV7RTB3YRTESTAVCNFSM6AAAAABCPVUGWOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRTGYYTINZQGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[henriquemoody]

I understand, and I'm sorry you are frustrated because your code doesn't work as expected. After all, that happened because we changed things, not you.

I insist that when you pass a format to the DateTime rule, it expects the input to match the format you pass to it. From the perspective of the rule, the value you're passing is Y-m-d\\TH:i:sP and not RFC3339.

In fact, PHP itself cannot parse all dates using that constant, even the ones mentioned in the RFC itself. See https://onlinephp.io/c/4609f

Reverting that commit will defeat the purpose of our date-related rules, and I will not do that. That change makes the rules more predictable and accurate.

[henriquemoody]

I suggest you add another rule to your chain, so it will accept yet another format v::dateTime('Y-m-d\TH:i:s.vp'). That will fix the issue you're having.

[oschwald]

If you look at the commit that mentions this issue, I did that. However, users of my library that happen to have a newer version of Respect/Validation with an older version of the library are still experience the breakage. The RFC3339 format intentionally allows Z while parsing as it is a valid representation

How do you suggest I deal with the other cases where this breaking change caused valid timestamps to fail, e.g., fractional seconds? For instance, 2014-04-12T23:20:50.05+00:00. It is a mistake to assume that a valid timestamp will round-trip to exactly the same string.