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

Programmer Humor

32479 readers
240 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
[–] [email protected] 15 points 11 months ago (11 children)

Only problem is accepting dates in anything except YYYYMMDD, or unix time stamps if you need more precision.

[–] [email protected] 15 points 11 months ago (7 children)

Neither of those will solve the problem in the comic.

[–] [email protected] 6 points 11 months ago* (last edited 11 months ago) (5 children)

EDIT: NVM I'm a goddamn idiot, Unix Time's handling of leap seconds is moronic and makes everything I said below wrong.


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.

[–] [email protected] 2 points 11 months ago* (last edited 11 months ago)

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.

load more comments (4 replies)
load more comments (5 replies)
load more comments (8 replies)