DST is my arch enemy.

"Why did I get paid for 7 hours instead of 8?"
"Because you worked from 1:00 till 9:00"
"Yeah, that's 8 hours"
"No it wasn't"

"Why does this input field say invalid time for 02:00?"
"Because that time doesn't exist"

"Why are so many tests failing"
"Because they check timestamps and durations which don't make sense in non-continuous time"

October is even worse...

@namenlossss it never did

@DataJockey @namenlossss

"If I give you one piece of candy per hour from 6am till 6pm, how much candy do you have?" -- "Uh... 12?"

"Now, if I give you one piece of candy per hour from 7am till 7pm, how much do you have..." -- "MORE CANDY BECAUSE 7 IS A HIGHER NUMBER?"

I often feel 95% of all people are just pretending to be adults 😫

That's why doing operations in timestamps with time zones is the way to go. If not, working with UTC.

February is almost as bad:

Me: Why does that test fail, I never touched that code? I see, because the time difference is 4 weeks not 1 month (=30 days).
* alert team *
Teammate: Why do we even need that function?
Me: How would I know, you fucking wrote it!

@AndSoWeCode Yeah my philosophy is that you should convert to a unified sensible format as soon as possible (input field should immediately convert to UTC or unix timestamp).

Then you only have to handle UTC in the backend and DB. You can display UTC by default, and convert it back when it hits the presentational layer (javascript) again.

Problem is, people themselves still get confused, even when the system itself is bug-free.

We’ve been dealing with this lately. For whatever reason someone decided it was a good idea to convert a datetime object to a Unix timestamp for UTC on the client side AND the server. So we were totally screwing the time up going into the dB. Coming back out though, we only converted it on the client side. Does nobody check things before release?!