219
DateTime (xkcd.com)
submitted 2 years ago by to c/programmerhumor@lemmy.ml
31 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 0 points 2 years ago (1 child)

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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 2 years 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).

  • permalink
  • fedilink
  • source
  • parent