Bug #76848 [Sus->Csd]: Possible to create Datetime from wrong month day

From: Date: Wed, 19 Oct 2022 15:18:03 +0000
Subject: Bug #76848 [Sus->Csd]: Possible to create Datetime from wrong month day
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-242631@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=76848&edit=1

 ID:                 76848
 Updated by:         derick@php.net
 Reported by:        wojciech dot mocek at gmail dot com
 Summary:            Possible to create Datetime from wrong month day
-Status:             Suspended
+Status:             Closed
 Type:               Bug
 Package:            Date/time related
 Operating System:   Linux
 PHP Version:        7.3.11
 Assigned To:        derick
 Block user comment: N
 Private report:     N

 New Comment:

I would be opposed to changing how date/time support works in PHP, so I am just going to close this
ticket.


Previous Comments:
------------------------------------------------------------------------
[2020-12-07 13:21:27] cmb@php.net

Okay, apparently Java implements truncation, but PHP implements
wrap-around (like date(1) does).  It is debatable which solution
is preferable, but since PHP implements wrap-around since
"forever", and the behavior is documented[1], changing that would
require the RFC process[2].  Feel free to start it.  For the time
being, I'm suspending this ticket.

[1] <https://www.php.net/manual/en/datetime.examples-arithmetic.php#example-2506>
[2] <https://wiki.php.net/rfc/howto>

------------------------------------------------------------------------
[2020-03-18 17:29:46] fzty at pm dot me

I encountered this issue on PHP 7.4.1 NTS x64. 
I tested a few more edge cases where an exception was expected but instead a DateTime object was
created:

# The zeroeth day of the month should not be accepted.
var_dump(new DateTime('2020-01-00')); // "2019-12-31 00:00:00.000000"

# The zeroeth month of the year should not be accepted.
var_dump(new DateTime('2020-00-00')); // "2019-11-30 00:00:00.000000"

# I'm not sure whether year 10000 should be accepted. 
var_dump(new DateTime('10000-01-01')); // "2000-01-01 10:00:00.000000"

Like wojciech said, this is not representative of real life scenarios. 
The end result is that we have to write extra boilerplate validation to handle such edge cases.

------------------------------------------------------------------------
[2020-01-20 17:39:27] girgias@php.net

Delegating this to Derick as he is the maintainer of the date extension.

------------------------------------------------------------------------
[2019-10-25 23:49:02] wojciech dot mocek at gmail dot com

This bug occurs also on PHP 7.3.11.

------------------------------------------------------------------------
[2019-10-25 23:40:42] wojciech dot mocek at gmail dot com

You asked "should both evaluate to the same value, shouldn't they?". So the answer
is: no, they should not. 
This is how it was solved in other object language:

$ docker container run --rm -it openjdk jshell
Oct 25, 2019 11:21:53 PM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
|  Welcome to JShell -- Version 13.0.1
|  For an introduction type: /help intro

jshell> var dateA = java.time.LocalDate.parse("2018-01-31");
jshell> dateA.plusMonths(1)
$2 ==> 2018-02-28

jshell> var dateB = java.time.LocalDate.parse("2018-02-31");
|  Exception java.time.format.DateTimeParseException: Text '2018-02-31' could not be
parsed: Invalid date 'FEBRUARY 31'
(...)


Do you agree that PHP DateTime class is class for handling date and time? If yes, then do you agree
that it should behave according to real date&time? If yes, then do we have in our calendar date
'2018-02-31'?

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=76848


--
Edit this bug report at https://bugs.php.net/bug.php?id=76848&edit=1


Thread (14 messages)

« previous php.bugs (#242631) next »