Some Notes About Time
unix4lyfe.org
Some Notes About Time
1–10 of 118 posts
Re: Some Notes About Time
#2Sigh.
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 seconds that have elapsed since midnight Coordinated Universal Time (UTC), 1 January 1970,[note 1] not counting leap seconds.[note 2] It is used widely in Unix-like and many other operating systems and file formats. It is neither a linear representation of time nor a true representation of UTC.
It follows on with a definition of Unix Time and points out various examples when it is ambiguous. These are real issues and can occur when missiles fly, when planes navigate, and when stocks are traded.
Time is tricky.
Re: Some Notes About Time
#3He missed to explain TAI and its relation with the other times.
Re: Some Notes About Time
#4GMT is not an old name for UTC. From http://www.bis.gov.uk/files/file32707.pdf :
Coordinated Universal Time (UTC) is based on International Atomic Time (TAI), but offset by an integer number of seconds so that it remains in approximate agreement with more traditional time scales based on the Earth’s rotation (i.e. Universal Time or, equivalently, Greenwich Mean Time). There is no natural gearing between TAI and GMT and so additional ‘leap seconds’ are applied when required to keep UTC in agreement with GMT to the nearest 0.9 seconds (see notes on time scales in Annex A for background information). UTC is the global standard for civil-time keeping today. It provides the most stable time base available because it is based on TAI, but also acts as a good approximation to its antecedent, GMT, for everyday purposes.
Re: Some Notes About Time
#5He missed to explain TAI and its relation with the other times.
Also, there have been many definitions of UTC, GMT etc over time. So to be truly correct you'd always have to mention which definition of UTC you are referring to when you use the term. And the ITU-R is debating to redefine UTC once again and remove leap seconds (http://www.ucolick.org/~sla/leapsecs/). If you are really interesting in the time stuff, here is a great resource: http://www.ucolick.org/~sla/.
Re: Some Notes About Time
#6Sigh. 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 software do precisely that. Most timestamps are just that: they don't care about "real world" details like leap-seconds, {23,24,25}hours per day, etc.
Because, in many case, you really don't give a flying shit about the "real-world" time.
What is your point? That a server that needs to open trade precisely at 9am has to take leap seconds into account? Sure. The article ain't disputing that.
But a lot of application basically only need timestamps and everything becomes much simpler when one starts to reason in milliseconds since the epoch instead of "real world" time.
Btw... Many of your "real issues" are due to programmers not realizing that they could have realized the exact same system but way more resilient had they knew to use timestamps instead of "real world" time.
There was an amazing paper by Google on the subject by the way, where they explained how they were reconciliating their hundreds of thousands of servers' time by allowing it to be "not correct" over x minutes / hours to dodge many issues.
And they clearly did emphasize that: a) these problems shouldn't have occured in the first place and were due to poorly designed programs (poorly designed in that they relied on real-world time instead of simply internally using milliseconds since the epoch) and b) most programs on earth do not give a flying ^^^^ if a time displayed to the user is one third of a second off...
Re: Some Notes About Time
#7Sigh. 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'
Yes and no: it might just exist theoretically, but we have no way to get at it. The closest we have is TAI, which is only an approximation of the time elapsed at mean sea level on the earthly geoid, because clocks fall victim to gravitational time dilatation and compression.
To accurately measure time you'd need a clock sitting perfectly still in space, and all other clocks in the universe would slowly drift behind it.
Re: Some Notes About Time
#8Funny 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..
Re: Some Notes About Time
#9Sigh. 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…
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 actually using that number.
Re: Some Notes About Time
#10Earlier 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…
I think you mean that unix time is seconds since the epoch minus leap seconds.