Trick to avoid all timezone bugs: represent times as Unix timestamps (i.e. a number) rather than your language's Time or Date object. Additionally makes time arithmetic much clearer, and is especially friendly when building an API where remote machines will parse the timestamp.

May 10, 2022 · 6:37 PM UTC

10
7
3
128
Replying to @gdb
Until you get to present it on frontend (say when showing when DALL-E generated an image) at which case, you're right back at timezone hell
1
Replying to @gdb
100%. Those leap seconds though.. stackoverflow.com/questions/…

Unix time and leap seconds

Regarding Unix (POSIX) time, Wikipedia says: Due to its handling of leap seconds, it is neither a linear representation of time nor a true representation of UTC. But the Unix date command does...

stackoverflow.com
6
Replying to @gdb
Yes. I love this "approach". That's the way I always model time-related logic, in particular, when I need to deal with timezones.
Replying to @gdb
this is the way
1
Replying to @gdb
Well actually… The DST rules can change surprisingly frequently so you can’t assume you’ll the timezone a future date will use. So you’d better save both the local time and the UTC time.
Replying to @gdb
There is no such thing as timezones. UTC is the only valid option. Sorry but I don't make the rules.
1
Replying to @gdb
I don't know if Python's datetime object holds an attribute for its timezone, but hopefully it does, otherwise that's really stupid
Replying to @gdb
Is there a reason to not use ISO8601
Replying to @gdb
Is there anyone who doesn’t do that? Sounds like hell converting cross-timezones and representations.
Replying to @gdb
yep. then just render/map it when helpful