LocalDate::utc() method

[zjbarg]

Hey!

What do you think about adding something like this to LocalDate

public static function utc(Clock $clock = null): LocalDate // or nowUtc
{
    return LocalDate::now(TimeZone::utc(), $clock);
}

and the same idea to LocalDateTime?

I'm doing this in my code LocalDate::now(TimeZone::utc()) and I'm wondering if a simpler syntax makes sense to other users.

[BenMorel]

Hi, following up here. Defaulting all now() methods to UTC would be a sensible default, but it's a tough decision, as I just gave arguments in favour of using the system timezone as a default in #113 (comment).

In particular, Java uses a default timezone:

public static LocalDate now()
Obtains the current date from the system clock in the default time-zone.

Which can be set:

• at JVM level (equivalent of php.ini or php -d)
• or using TimeZone.setDefault() (equivalent of date_default_timezone_set())

@zjbarg What's your opinion on this, one year later?

[solodkiy]

I think avoiding concept of default_timezone is one of the best advantages of this lib. So, please don't break it)

[BenMorel]

@solodkiy Thanks for your feedback!

One solution that I've used in the past (in an application where only a single timezone was relevant) was to add a TimeServiceInterface to our codebase, which was our entrypoint to get a now instance of various date-time objects: nowLocalDate(), nowZonedDateTime() etc. This was useful for multiple reasons:

• the default timezone was set in Symfony config files
• the service could be injected anywhere we needed to retrieve the current date and time
• this made the application testable, as we were now able to inject a TimeServiceMock instance in tests

This service could be part of brick/date-time.

Another solution could be to add a timezone to the Clock interface (which is what Java does, and what PSR-20 does as well through DateTimeImmutable), so that your application could simply inject a Clock into your services. You'd now do:

class MyService
{
    public function __construct(
        private Clock $clock,
    ) {}

    public function doSomethingWithDate()
    {
        $today = LocalDate::now($this->clock);
    }
}

This solution is interesting:

• it brings a default timezone with it
• it doesn't need to change the fact that LocalDate::now() requires an explicit timezone
• you can also inject it through DI, and have the default timezone in the application's config
• it bridges the gap with PSR-20 (we could now convert clocks back and forth between brick and PSR-20)
• you also get testability for free: now that your application uses an explicitly Clock everywhere, you can easily inject a FixedClock in tests

What do you think?

[zjbarg]

Hi, following up here. Defaulting all now() methods to UTC would be a sensible default, but it's a tough decision, as I just gave arguments in favour of using the system timezone as a default in #113 (comment).

In particular, Java uses a default timezone:

public static LocalDate now()
Obtains the current date from the system clock in the default time-zone.

Which can be set:

* at JVM level (equivalent of `php.ini` or `php -d`)

* or using `TimeZone.setDefault()` (equivalent of `date_default_timezone_set()`)

@zjbarg What's your opinion on this, one year later?

@BenMorel It is NOT trivial for myself to switch from an app developer mindset to a package maintainer mindset, I will not attempt to.

I have always found defaults to be a bitter sweet, they have their place, but I will always seek to be explicit. I would go toward allowing the default to be the system default for those who like to use it, that is, keep everything as is, changing defaults is a can of worms I don't like to open.

Adding a static nowUtc method would allow us to be more explicit with ease, and it does not affect current defaults and a future change in the default behavior.

[BenMorel]

Hi @zjbarg, sorry I mixed up a bit the concerns with #113 here. Even if your feature request is related, it is really about adding a helper method, not changing the defaults.

If we keep the library in its current state, your solution is acceptable IMO.

But I'm starting to think that always requiring a Clock (that would come with a timezone) could actually be a good thing for the library, as it improves testability and robustness, at the expense of ease of use. This change would likely make your request obsolete (you'd most likely inject a UtcClock everywhere you need it).

I'd appreciate feedback on this one!