fig-standards VS date-time

The namespaces and class names must follow this example.

I would familiarize yourself with the following PHP standards: https://www.php-fig.org

The PHP Standard Recommendation, or PSR for short, from the aforementioned PHP-FIG.

That's what happens if you use a PSR-4 autoloader and not utilise PSR-4 in your project structure 👀 So either use PSR-0 or properly use PSR-4.

PHP really "got it's act together" in my view when packagist and composer (which are PHP's equivalent of npm) became mainstream and with the release of the PSR community standards. We were admittedly a little behind the curve with regards to package managers but with standardised formats and not having to copy and paste zip file libraries anymore, PHP received a new lease of life.

brick/date-time: Date and time library for PHP

brick/date-time: Date and time library for PHP

If you're happy to bring in another library, you could replace your Date VO class with the LocalDate class from the brick/datetime library. It does the same thing, just has three int fields inside instead of a string in Y-m-d format.

If you need to store subsets of a date-time-timezone combination, then take a look at brick/date-time instead.

Slightly related but https://github.com/brick/date-time is a wonderful library to manage datetime concepts in a proper way.

Looks like a CivilDate is the same thing that brick/date-time calls a LocalDateTime. Does this library have any advantages over the one from Brick?

I like https://github.com/brick/date-time

It is a good practice to use an interface to manage the clock in an application, as it allows having full control of time. For example, it eases testing, as it lets us define the concrete time for each test. Frank de Jonge and Matthias Noback have blog posts about it, brick has an implementation, and there is even a PSR proposal to have a ClockInterface.