date-time VS Carbon

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.

Carbon is probably one of the most popular vendors to handle dates in PHP.

Official page, at the very bottom.

Let me start by referring you to PHP's DateTime implementation. There is a library called Carbon that uses this DateTime implementation and added almost all the methods you have (but better). So there really is no need to create your own just to be able to display Dutch names. That way to can get rid of the nasty "globals".

At first we go to https://carbon.nesbot.com/ Here we will see a lot of interesting information and go deeper into it See also https://github.com/briannesbitt/Carbon

first of all, i think you should use Carbon library. it's available here: https://github.com/briannesbitt/carbon

See: https://github.com/briannesbitt/Carbon/issues/1693

Working with datetime in PHP could be a real pain if you don't take advantage of popular libraries like Carbon. It's all good until you have to convert dates provided on user input into another timezone (eg. UTC) and vice versa. Other example could be that you have to manage various input datetime formats, and sanitize them into a consistent one before saving it to database.

Be careful of floatDiffInMonths() which can gives you a lower result (number of months in A < number of months in B) for an interval having more days (number of days in A > number of days in B) due to the variable number of days in months (especially February). By default, we rely on the result of DateTime::diff which is sensitive to overflow. See issue #2264 for alternative calculations.