LocalDate::now($timezone /*= system TimeZone*/)

[nkamuo]

The LocalDate::new(), LocalTime::new() and LocalDateTime::new() all require the timezone parameter.
It would be a lot easier to use if the ::now() method's timezone parameter is optional and defaults to the configured php TimeZone.

[zjbarg]

that's kinda what I'm referring to in #111

Making it easier to use generally.

[BenMorel]

Hello,

Sorry for the late reply. This was a design choice that I made to ensure that developers always make a conscious decision when selecting a timezone. In my experience, blindly calling now() while implicitly relying on a value set in php.ini is a future source of bugs, as your application's behaviour is now dependent on server configuration, instead of application configuration, where I think this information typically belongs—when your application only deals with a single timezone.

That being said, there are solid arguments against my own opinion:

• Java's LocalDate::now() can be called without arguments (using the system timezone as a default)
• PSR-20 has since been ratified, and its ClockInterface::now() returns a DateTimeImmutable, which includes timezone information (defaulting to the system timezone if you just return new DateTimeImmutable()); if we ever integrate with PSR-20, ignoring the timezone information returned by this interface would be silly.

So I may revisit this design choice .

[brunocassol]

developers always make a conscious decision when selecting a timezone

I agree with this decision. Timezone is not something you want an implicit default when dealing with dates.

And applications can always define an explicit default timezone and pass that. Something like LocalDate::new(MY_APP_DEFAULT_TIMEZONE).