Time math is one of the most headache inducing parts of any programming project. I'd rather deal with uncommented recursion and regex.

DSTs.

The thing that turns any time based calculation into a special circle of hell...

@IntrusionCM Just use UTC internally. That way, you only need to pull in a conversion library for input / output.

I like the Temporal API

@Fast-Nop that's the correct way, yes.

I learned the DST lesson when dealing with databases who didn't do that...

It was a mind boggling adventure.

(the kind of database who were bad in design and whose input wasn't properly validated, too.....)

I made a mistake when building out my database logic and everything was being store in my time zone. I fully intended to store everything in UTC.

I fixed that but forgot to fix where I was comparing time in my time zone and not UTC.

I fixed that, but I found out I subtracting negative time, meaning that I was adding times together, which explained the very weird timestamps I was getting.

This is my first real project in Python that deals with a database and time math. I am usually working in Rails which does a lot of this for me. Between Rails and Ruby, I've been spoiled with their crazy intuitive time math logic.

The aha moment when I got it nailed down was cathartic.

Convert everything to Unix timestamp. Easy Peasy.

@Sid2006 not really.

Timestamps are inferior to actual date / datetime objects.

While Linux assumes timestamp being UTC... Most time APIs don't.

A timestamp has no timezone.

@IntrusionCM I have literally never seen an API that treats a timestamp as anything other than the number of (mili/nano/)seconds since 1970-01-01 00:00 UTC excluding leap seconds, which is its definition. What does this?