php / php-src

The PHP Interpreter
https://www.php.net
Other
38.18k stars 7.75k forks source link

Why PHP does not have a Date class? #15679

Open ghost opened 2 months ago

ghost commented 2 months ago

Description

Some of my properties represent a Date (2024-08-31), not a Date and Time (2024-08-31 15:10:00). Right now I have to use DateTimeImmutable type hint what gives wrong information about what a property represents.

I wonder why PHP still doesn't have Date class in 2024. Isn't is as simple as removing time information and time related methods from DateTime class? Date and DateTime instances would be comparable (==, >, < etc.) and during the comparison the time for Date instance would be implicitly 00:00:00.

P.S. Ofc Date class should be immutable so PHP doesn't end up with Date and DateImmutable :smile:

Best

cmb69 commented 2 months ago

I wonder why PHP still doesn't have Date class in 2024.

Maybe because there is no such thing as a date (well, there are local dates, but that class is simple to write in userland).

ghost commented 2 months ago

@cmb69

Maybe because there is no such thing as a date

What do you mean by that? A date is a point on the timeline that is identified by a year, month an a day. A date doesn't consider time (if needed then it's implictly 00:00:00, e.g. when comparing with DateTime). Examples: birthday, manufactured date, expiration date. Am I missing something?

there are local dates

Could you elaborate or give some reference? I'm not familiar with this term.

simple to write in userland

I could write a Date class in userland but I would like to be able to compare this with DateTime with >, <, == etc. operators. Unfortunatelly PHP does not have operator overloading. Also I would like developers to work with Date class the same as with DateTime, except time information. I would like developers to treat Date class as a subconcept of DateTime.

cmb69 commented 2 months ago

Examples: birthday, manufactured date, expiration date. Am I missing something?

That are prime examples of local dates, that is dates with no associated timezone. As soon as a timezone is associated, you can no longer ignore the time.

I could write a Date class in userland but I would like to be able to compare this with DateTime with >, <, == etc. operators. Unfortunatelly PHP does not have operator overloading.

That is somewhat unfortunate, indeed, but you still can have respective methods, and that doesn't read that bad, e.g.

$date->gt($other)
$date->eq($other)

Note that I'm not saying that there shouldn't be a Date class, but the issues need to be sorted out carefully. It is not even clear whether such a Date class would fit into ext/date. Alternatively, there could be a JulianDay class in ext/calendar, for instance.

Anyhow, I think this feature requires the RFC process.

ghost commented 2 months ago

Yeah, I've also noticed that timezone may not make sense in Date concept. I see a Date class as a model for a... date :slightly_smiling_face: , i.e. year+month+day. A class that does not consider a time and developer must be aware of that. This is a common concept in real life. You can hear many people saying "I have a visit in medical center on May 27", "My parcel will be delivered on May 27", "School year starts on Septemper 1". Most of applications work in fixed timezone and the date is always considered at this timezone.

Having such a class and type hint as a consequence would result in more descriptive code, better model. Right now we have to write DateTimeImmutable $courierDate where $courierDate is a date when courier will pickup a delivery but DateTimeImmutable gives information that there may be some time involved.

but you still can have respective methods, and that doesn't read that bad, e.g.

Yeah. However it using >, < etc. is more intuitive. Having to compare DateTime with >, < and Date with ->gt(), ->lt() is not that good DX.

cmb69 commented 2 months ago

Note that it doesn't make much sense to further state your case in this ticket. Instead write to the internals mailing list where the details can be discussed. From there, an RFC may arise (or not).

6562680 commented 2 months ago

Agreed, day comparation is a task that i've just met on every job am doing. Time - more rarely case, usually about generation dates sequence and checking is the time between "from-to". But day comparation - is about caching, about indexing, about configuring something - too many cases.

Agreed that the class could be implemented to make thing easier.

About immutability... Immutability is a tool. For example - if i expect date from user - usually i need to copy date only once - from user input to DTO. I dont need date copied on every method call. Only first time.

But once i work with databases where i get date, then add some time to check logic - there's big possibility to make some mistakes. So immutability is a good additional. But creating immutable dates (that is copy object and forces constructor call on each action) by default just because "there may be a mistake" - wrong way, for me.

ghost commented 2 months ago

About immutability... Immutability is a tool. For example - if i expect date from user - usually i need to copy date only once - from user input to DTO. I dont need date copied on every method call. Only first time.

Date immutability is not about how one prefers to work with object. It's about design. Object oriented programming is about using objects to represent real life concepts. In this case we have a value representing some date and we use Date class to represent this value in OOP manner. When you have a date 2024-09-09 you represent it as a Date(2024, 9, 9) object. Now, when you add 1 day then you have completely another date so you have to create a new Date instance representing this date.

I would also like to mention that immutability = security. Try to debug a bug the was caused because some developer modified the object on the other side of the system. Ofc you can clone everywhere but extensive cloning is a code smell showing that maybe this object should be immutable at the beginning.

cmb69 commented 2 months ago

Note that it doesn't make sense to discuss further details here. Instead write to the internals mailing list where these can be discussed. From there, an RFC may arise (or not).

derickr commented 1 month ago

I've also been collecting new Date/Time API ideas at https://docs.google.com/document/d/1pxPSRbfATKE4TFWw72K3p7ir-02YQbTf3S3SIxOKWsk/edit#heading=h.2jol7kfhmijb

6562680 commented 1 month ago

Take a look of extending core \Date classes for you needs:

https://github.com/6562680/calendar

Because the most painful thing about programmers on our planet is that most of them want to write themselves into history by turning their new ideas (features, possibilities) into something bigger, instead of helping solve existing problems with minimal actions.