this post was submitted on 14 Dec 2023
220 points (95.8% liked)
Programmer Humor
32559 readers
637 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Unix time fails to work for the 'simple' case of timezones entirely. It's not meant for timezone based data and therefore unixtime in one timezone subtracted from unix time in another timezone will most likely give completely incorrect results. Even in the same timezone it will give incorrect results, see the 'simple' case of a country jumping across the international date line. Typically they skip entire days, none of which unix time will account for, as that would require not just time zone data, but location data as well.
You misunderstand what Unix Time is. It's the number of seconds since 1970-01-01T00:00+00:00. It's always relative to UTC. And the number of seconds since epoch is always the same regardless of where you are on Earth.
As I write this it's
1702600950for you, for me, and in Sydney. Timezones (and DST, and leap seconds, and other political fuckery) only play a role once you want to convert1702600950into a "human" datetime. It corresponds to2023-12-15 00:46:02 UTCand2023-12-14 16:46:02 PST(and the only sane and reliable way to do the conversion is to use a library which depends on the tzdata).