Live data from Hacker News

Some Notes About Time

unix4lyfe.org

11–20 of 118 posts

Re: Some Notes About Time

#11
post #2

Sigh. 50 year old numerical / geophysical / real time data acquisition/processing/interpretation programmer here. Unix Time isn't much chop for "real time" continuous data from the "real world" - it's those pesky leap seconds. If you bother to read the first paragraph of the wikipedia article on Unix Time you'll see : > Unix time, or POSIX time, is a system for describing instances in time, defined as the number of s…

Bummer. I hope that the author reads your comment, because it's otherwise a very useful page. I'd love to have a reference like the OP's about time and everything a programmer needs to know about it without problems like the one you're subscribing. This one's almost there.

Thanks for clarifying!

Re: Some Notes About Time

#12
Who was the genius who decided that unix time should handle leap seconds? It seems like such an obviously bad idea. The biggest advantage of unix time has always been that it is monotonically increasing and that it is precisely defined as seconds since the epoch, period. And then all of that is now broken because of this decision.

Also, does the problem that the leap second solves actually warrant all of the problems that it causes?

Re: Some Notes About Time

#13
post #2

Sigh. 50 year old numerical / geophysical / real time data acquisition/processing/interpretation programmer here. Unix Time isn't much chop for "real time" continuous data from the "real world" - it's those pesky leap seconds. If you bother to read the first paragraph of the wikipedia article on Unix Time you'll see : > Unix time, or POSIX time, is a system for describing instances in time, defined as the number of s…

Time is tricky but there is a simple fact: it exists such a thing as the number of actual seconds elapsed since 'time x' (typically the Unix epoch but anything else will do too). No leap seconds issues. No 25 hours-day issues. No 23 hours-day issues. No 59 seconds minutes issues. No 61 seconds minutes issues. And all it takes to store a time like that is a 64-bit integer and it is very convenient. And a lot of softwa…

> Time is tricky but there is a simple fact: it exists such a thing as the number of actual seconds elapsed since 'time x' (typically the Unix epoch but anything else will do too).

Yeah. Hmm. Clearly an opinion expressed without either reading, comprehension, or experience.

Why would I say that? Well, consider your statement about "actual seconds elapsed since epoch". Leaving aside the fact that Unix Time enumerates no such thing (and it was Unix Time I was discussing), there are such things as time frames and relativistic effects which come into play when doing fine scientific measurement, astronomical work, and ground satellite communications.

There are levels to dealing with time and the linked article makes a decent first order stab at climbing the ladder, even ground based programmers need to be wary of the leap seconds issue and the plethora of time standards with minute but significant (in some context or another) issues.

When you've cooled down a little consider the title "What every programmer should know ...". Had it been "What most programmers can skate by on" I probably wouldn't have bothered to comment.

I agree there are many good papers on the subject, going back decades, I'm betting the google paper you speak of references a classic one on time stamps and relativity as some times local event order trumps universal order (and in fact the paper pivots on the observation that universal order doesn't really exist, just effective order).

Re: Some Notes About Time

#14
post #9

Earlier quoted context omitted.

Time is tricky but there is a simple fact: it exists such a thing as the number of actual seconds elapsed since 'time x' (typically the Unix epoch but anything else will do too). No leap seconds issues. No 25 hours-day issues. No 23 hours-day issues. No 59 seconds minutes issues. No 61 seconds minutes issues. And all it takes to store a time like that is a 64-bit integer and it is very convenient. And a lot of softwa…

Things do indeed become much simpler when you reason in milliseconds since the epoch. So why is it so rare to do so? UNIX time is not milliseconds since the epoch. It's milliseconds since the epoch, plus the leap seconds that have accumulated over that period. The only widely used timebase that's pure milliseconds since the epoch that I'm aware of is GPS time, and basically everything adds in the leap seconds before…

[deleted]

Re: Some Notes About Time

#15
post #9

Earlier quoted context omitted.

Things do indeed become much simpler when you reason in milliseconds since the epoch. So why is it so rare to do so? UNIX time is not milliseconds since the epoch. It's milliseconds since the epoch, plus the leap seconds that have accumulated over that period. The only widely used timebase that's pure milliseconds since the epoch that I'm aware of is GPS time, and basically everything adds in the leap seconds before…

I think you mean that unix time is seconds since the epoch minus leap seconds.

[deleted]

Re: Some Notes About Time

#19
He did not mention the issue that some processors might have different time counting for each core, sometimes resulting in very silly situations if you are reading time in milliseconds or below scale.

For example: I had a game that physics behaved "woobly" in multi core systems. The issue is that as the OS juggle your process around, you get the delta time since last physics step inaccurate, sometimes even with backwards jump in time ( and according backward movement in the game ).

Later I saw someone showing the effects of this on the file system, with a multithreaded file copy resulting in very strange timestamps.

For my game, the solution was force time-dependant threads to request affinity with one core.

Re: Some Notes About Time

#20
post #8

Funny I read the title and thought: TVM but then realized it was the age old quest for time keeping and dreaming of ways to track it with reasonable sanity.. :-) Bonus points for anyone who knows what I mean by TVM and can describe why every programmer should know about it..

I can only think of Time Value of Money...
Post reply on HN