this post was submitted on 14 Dec 2023
219 points (95.8% liked)

Programmer Humor

32716 readers
305 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[โ€“] snowe 0 points 1 year ago (1 children)

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.

[โ€“] [email protected] 3 points 1 year ago

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 1702600950 for you, for me, and in Sydney. Timezones (and DST, and leap seconds, and other political fuckery) only play a role once you want to convert 1702600950 into a "human" datetime. It corresponds to 2023-12-15 00:46:02 UTC and 2023-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).