221
DateTime
(xkcd.com)
Post funny things about programming here! (Or just rant about your favourite programming language.)
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.
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/orT2
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:
(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.When you're saying Unix time does not include leap seconds, you are making exactly the wrong conclusion. Unix time is not a monotonically increasing number of seconds since the Epoch, because it excludes those seconds which are marked as leap seconds in UTC. I.e. the time between now and the Epoch was larger than the current Unix time shows (by exactly the number of leap seconds in between). See e.g. https://en.wikipedia.org/wiki/Unix_time#Leap_seconds
Aight I'm just dumb then. Now the question is who the fuck thought this was a good idea? Probably someone so naive they thought it'd make time conversions easy...