you know what will solve those problems though? blame them on someone else. “oh yeah that bug, yeah sorry the package we’re using messed it up, there’s a PR for that”
Unix Time is an appropriate tool for measuring time intervals, since it does not factor in leap seconds or any astronomical phenomenon and is therefore monotonously increasing… If T1 and/or T2 are given in another format, then it can get very hairy to do the conversion to an epoch time like unix time, sure.
The alt-text pokes fun at the fact that due to relativity, at astronomical scales then time moves at different speeds. However, I would argue that this is irrelevant as the comic itself talks about “Anyone who’s worked on datetime systems”, vanishingly few of which ever have to account for relativity (the only non-research use-case being GPS AFAIK).
While the comic is funny, if:
Your time source is NTP or GPS
“event 1” and “even 2” both happen on Earth
You’re reasonably confident that the system clock is functioning properly
(All of which are reasonable assumption for any real use-case)
Then ((time_t) t2) - ((time_t) t1) is precise well within the error margin of the available tools. Expanding the problem space to take into account relativistic phenomena would be a mistake in almost every case and you’re not getting the job.
Clock misalignment comes up pretty frequently in some networking and networking-esque applications. Otherwise, yeah, the edge cases are indeed on the edge.
Subsecond precision comes up often in common applications too, but you can just expand out to milliseconds or whatever.
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 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).
Only problem is accepting dates in anything except YYYYMMDD, or unix time stamps if you need more precision.
Neither of those will solve the problem in the comic.
you know what will solve those problems though? blame them on someone else. “oh yeah that bug, yeah sorry the package we’re using messed it up, there’s a PR for that”
Unix Time is an appropriate tool for measuring time intervals, since it does not factor in leap seconds or any astronomical phenomenon and is therefore monotonously increasing… If
T1and/orT2are given in another format, then it can get very hairy to do the conversion to an epoch time like unix time, sure.The alt-text pokes fun at the fact that due to relativity, at astronomical scales then time moves at different speeds. However, I would argue that this is irrelevant as the comic itself talks about “Anyone who’s worked on datetime systems”, vanishingly few of which ever have to account for relativity (the only non-research use-case being GPS AFAIK).
While the comic is funny, if:
(All of which are reasonable assumption for any real use-case)
Then
((time_t) t2) - ((time_t) t1)is precise well within the error margin of the available tools. Expanding the problem space to take into account relativistic phenomena would be a mistake in almost every case and you’re not getting the job.Clock misalignment comes up pretty frequently in some networking and networking-esque applications. Otherwise, yeah, the edge cases are indeed on the edge.
Subsecond precision comes up often in common applications too, but you can just expand out to milliseconds or whatever.
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).ISO 8601, it’s the only way.
deleted by creator
https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca