timestamps with TZ offset

why.... WHYYYY???????

because.... timezones exist?

Because not everything is UTC based, I know... crazy concept!

@tosensei For epoch timestamps? They don't

@C0D4 epoch timestamps aren't UTC. They are an offset in (mili)seconds from a global event. It should be exactly the same everywhere in the world, regardless the TZ

@netikras Who encodes a unix timestamp as a datetime though

@netikras well, maybe at some point you need the information what the users _local time_ was during the timestamp.

so: yes. timezones exist. get used to using them. or at some point, some incompetent admin is moving your app to a different server configured with a different time zone and everything will be broken (happened recently to an app i've inherited)

@tosensei At $work, everything is in PST. All servers, regardless of location, all dev environments, all meeting times, etc. Everything is in PST. Why? They couldn’t figure out how to handle timezones. 🤦🏻‍♀️

@12bitfloat someone who wants to know what date/time 1758937379 is without running it through a converter

@spongessuck 1758937379 with +7h tz offset becomes a 1760449379. Is that better now? No need for a converter?

Not only you still need a converter, you also have fucked up a timestamp for anyone trying to interpret it

edit: sry, just now I noticed your comment wasn't meant for me

Timezones and DST.

Timezones aren't bad. DST is like super villain evil bad.

Especially in commercial situations cause you have an hour in DST change that simply does not exist. Or better: It must not exist.

So you need the timezone and you better not fuck it up with the DST...

... Otherwise you'll end up with a lot of unpleasant red tape to unfuck the mayhem.

@IntrusionCM how is a TZ offset in an epoch timestamp a good thing? Esp when returned through a public api?

@netikras when you *must* know the timezone of the origin.

As said, in commerce this can be with DST an requirement.

@IntrusionCM but you *DON'T* know the tz of the origin. You only know the already incremented long value. But don't know by how much

I slowly begin to understand where your trouble lies.

For me timestamp with timezone means that the timezone information is encoded in integer representation at a fixed position.

The timestamp is in UTC, the timezone is an additional information encoded in the integer.

You're talking about sth else. Right?