Difference between 2023-01-01 00:00:00 and 2023-12-31 23:59:59 is 11 months, 29 days, 23 hours, 59 minutes, 59 seconds ; so almost a year (by one second)

Difference between 2023-01-01 00:00:00 and 2023-01-31 23:59:59 is the same, almost a month by 1 second.

Same for february (even with 28 being the last day).

But then, 2023-03-01 00:00:00 and 2023-03-31 23:59:59 gives me :
1 month, 2 days, 23 hours, 59 minutes, 59 seconds.

WHY, are there fucking 34 days in March ? Is this a bug ? Is it confused with February being the previous month ?
Why would PHP do this to me ?

Why the hell is it always so painful to work with dates, it's not even like I'm stretching the standard library or using raw timestamps to hack things together

I used the diff method of PHP 7.4 DateTime, is someone wants to try it

Ask chatgpt

Even DST can't explain it.

@chatgpt Difference between 2023-01-01 00:00:00 and 2023-12-31 23:59:59 is 11 months, 29 days, 23 hours, 59 minutes, 59 seconds ; so almost a year (by one second)

Difference between 2023-01-01 00:00:00 and 2023-01-31 23:59:59 is the same, almost a month by 1 second.

Same for february (even with 28 being the last day).

But then, 2023-03-01 00:00:00 and 2023-03-31 23:59:59 gives me :
1 month, 2 days, 23 hours, 59 minutes, 59 seconds.

WHY, are there fucking 34 days in March ? Is this a bug ? Is it confused with February being the previous month ?
Why would PHP do this to me ?

Why the hell is it always so painful to work with dates, it's not even like I'm stretching the standard library or using raw timestamps to hack things together

I used the diff method of PHP 7.4 DateTime, is someone wants to try it

@electrineer
out and confirm this behavior. It seems that the DateTime class considers March to have 34 days instead of 31, which is definitely not correct.

However, it's important to remember that dealing with dates and timezones can be a complex task, and there may be some edge cases or quirks in certain programming languages or libraries. It's always a good idea to double-check your code and ensure that it's behaving as expected, especially when working with critical systems or sensitive data.

If you're encountering unexpected behavior with date and time calculations, there are several resources available online that can help you troubleshoot and find solutions. Additionally, many programming communities have forums or discussion groups where you can ask questions and get feedback from experienced developers.

Lol, that answer was very different from what it answered when I tried it first in my spam thread, and that one made no sense either (claiming that DST makes March longer even though it obviously makes it shorter, and that would make up for only one hour). Funny how it completes my last sentence.

A month is not defined correctly. use number of days instead.

@magicMirror but I need months, and I explicitly use the standard library to avoid these kinds of raw calculations on dates. This behavior isn't even documented (if it was, I wouldn't have ranted about it)

"Why the hell is it always so painful to work with dates" because dates are an arbitrary, non rational system based on natural, non rational physics that don't like to play by any rules. but there's a fix: mount some huge thrusters to our planet and fix its rotation and orbit so we get years and days that are easier to model

I read the whole thing and then I got to the part where it says "PHP". Ha. Good luck, have fun, and sure as hell hope something bigger's watching over you

There is only january and it has 365 days. 2023-01-01T00:00:00.000 until 2023-01-365T05:48:49.972

Everything works out with this date system

@electrineer chatGPT is just a pro in giving bullshit

What TZ offset? Maybe it thinks your actual start date is Feb 28 and it's not a very good date library.

PHP datetime has issues.

@hippolyte try Carbon (am on train so can't confirm if this bug is present in it too): h t t p : // carbon.nesbot . com

^ I have a feeling it might have same issue, but could be worth a look

Seems to work just fine in 7.4.27, also fine in 7.2.19 - which version are you running?

Any chance you accidentally diffed 2023-02-01 and 2023-02-31?

@spongegeoff @electrineer I'll tell you when I get back to work

@hippolyte This is why devs need weekends - hope there's a straightforward explanation, even it's just the particular release of 7.4 not being good.

Of course any program would be confused when you asked date difference in: month, days, hours, minutes, seconds. You should make up your mind and choose whether it's month or day difference. You can't ask for both.

Why can't you? Because our calendar system is quirky. What's the date difference between January 1st and February 1st? One month? What's the date difference between February 1st and March 1st? One month as well?

The first one differs by 31 days and the second differs by 28/29 days though.

You have to pick one and roll your own code. It depends on what you/your company wants.

I am kinda doubtful that PHP would answer wrong regarding the date difference of March 1st and March 31st, though. That should be fine.

Chatgpt parroted what people asked and gave out wrong answer as usual. Why am I not surprised?

@spongegeoff @electrineer @daniel-wu

https://pastebin.com/iJKD1aML

As stated, tested with PHP 7 and 8 on the same windows machine, and the latter doesn't have the problem. I also tested it in a debian VM with PHP 7.4.33 (slightly more recent) and it's the same as windows' PHP 7.

It also fucks up other months as you can see.

For the record my timezone identifier is Europe/Berlin so CEST now (even CET 2 days ago)

May be a simple difference in month representation, but then I don't get the inconsistencies between january, march, and may

@topsecret230 "consule the oracles."

basically.

"Why would PHP do this to me ?"

"PHP"

Theres your answer.