search

cakephp / chronos

A standalone DateTime library originally based off of Carbon
http://book.cakephp.org/chronos
MIT License
1.34k stars 61 forks source link

[Question] Is there a way to have chronos properly validate the input against request format? #407

Closed andrei-dascalu closed 10 months ago

andrei-dascalu commented 11 months ago

When using createFromFormat the behaviour seems to mimic the built-in PHP DateTime class which has some inconsistencies. Eg:

createFromFormat('Y-m-d', '20-11-11');

will produce 0020-11-11, padding digits instead of validating against the requested 4-digit year. Opposite that, Y-m-d H used against the same value will result in an error (false returned) as opposed to filling in the missing hour with zeroes.

Would it be possible for Chronos to provide some consistent alternatives that would enforce formats rather than randomly padding in various situations?

othercorey commented 11 months ago

The only real alternative we have is ICU format parsing. That is supported in cakephp's I18n classes but not Chronos directly. I'm not sure if their 4-digit year formatter accepts 2 digits or not.

andrei-dascalu commented 10 months ago

@othercorey In Chronos v2, the method getLastErrors would return warnings for improperly formatted dates in the sense that for example you would have 2021-11-11 10:90:30 there would be a warning that minutes are not valid (even if the minutes would be processed in an overflow way, result in the time 11:30:30) so that the user would be able to decide what to do.

However now that this method has been removed, I'm not sure how validation standards could be maintained on client side. I thought Chronos v3 would be throwing errors in those cases where getLastErrors would return stuff, but it doesn't seem to be the case (completely).

othercorey commented 10 months ago

We can re-introduce the getErrors() helper since Chronos still uses DateTimeImmutable for parsing. It's less obvious tha's happening in Chronos 3 since it doesn't extend DateTimeImmutable, but should be easy to document in the docblock.

andrei-dascalu commented 10 months ago

Sounds good, that would be helpful to be able to retrieve the warnings.

I guess it's difficult to have a balance - personally I see logic in throwing an exception for invalid minutes / seconds rather than silently overflowing into unexpected values as PHP does by default but perhaps that's too much of a breaking behaviour?

In terms of other validation it would be great to have a sort of optional strict parsing mode that would throw exception if the string doesn't fit the pattern perfectly. I'm not sure how others feel about it.