When $hour is null, the current time is used for any time component that is also null.
When $hour is 0, 0 is used for any time component that is also null.
Examples:
Chronos::create(2023, 1, 1);
Will use now for the hour, minute second and microsecond.
Chronos::create(2023, 1, 1, 0);
Will use 0 for the hour, minute second and microsecond.
Issues
With named parameters, if you set only the $minute argument to 0, the hour, second and microsecond would still use now. This feels counter-intuitive.
Chronos::create(2023, 1, 1, minute: 0); // this will create something like "2023-01-01 13:00:02.125523"
This behavior is different from constructing a DateTimeImmutable without including the time components:
new DateTimeImmutable('2023-01-01'); // this will create "2023-01-01 00:00:00"
Proposal
Change the default values for $hour, $minute, $second and $microsecond to 0.
Users can still specify null to get now, but they will have to specify it for all time components. There are simpler ways to create a Chronos instance of now so this doesn't feel like a harsh requirement.
We would like to get feedback from the community on an idea for the time values in
Chronos::create()
for Chronos 3.Current Behavior
The signature for
Chronos::create()
currently looks like this:The current behavior is:
$hour
isnull
, the current time is used for any time component that is alsonull
.$hour
is0
, 0 is used for any time component that is alsonull
.Examples:
Will use
now
for the hour, minute second and microsecond.Will use
0
for the hour, minute second and microsecond.Issues
$minute
argument to 0, the hour, second and microsecond would still usenow
. This feels counter-intuitive.DateTimeImmutable
without including the time components:Proposal
Change the default values for
$hour
,$minute
,$second
and$microsecond
to0
.Users can still specify
null
to getnow
, but they will have to specify it for all time components. There are simpler ways to create a Chronos instance ofnow
so this doesn't feel like a harsh requirement.