Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some Notes About Time

unix4lyfe.org

Post reply on HN
Print view View original

61–70 of 118 posts

Re: Some Notes About Time

#61

Post by tommorris »

mbq wrote: post #60
tommorris wrote: post #51

Time is even more complicated than that because of vagueness, either intentional or unintentional. Humans represent time vaguely rather than precisely. Computers tend not to. A while back, the British Library catalogue was put online as linked data. The library cataloguers had added details of author birth and death years but not always birth dates . But the data model normalised "1941" to "1941-01-01". (They fixed i…

The author only advices to use UNIX time to precisely measure time intervals and store precise timestamps; your points are of course valid, but they are not a reason to degrade precise data into human-readable pandemonium.

Ah, my mistake. I'll rephrase my original comment.

Re: Some Notes About Time

#62

Post by piqufoh »

"the Prime Meridian was (arbitrarily) chosen to pass through the Royal Observatory in Greenwich"

At the International Meridian Conference in 1884 41 delegates from 25 nations met in Washington, D.C., USA and selected the meridian passing through Greenwich as the official prime meridian due to its popularity - not an arbitrary decision ;)

However, the French abstained from the vote and French maps continued to use the Paris meridian for several decades.

Re: Some Notes About Time

#63

Post by Dylan16807 »

masklinn wrote: post #7
martinced wrote: post #6

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…

> 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…

You're forgetting to factor in accuracy/resolution. TAI is completely perfect down to the picosecond level and further. That means you do have the number of actual seconds, milliseconds, microseconds, nanoseconds...

You only encounter issues with TAI once you get down to femtosecond or smaller levels.

Re: Some Notes About Time

#64

Post by rolux »

tommorris wrote: post #51

Time is even more complicated than that because of vagueness, either intentional or unintentional. Humans represent time vaguely rather than precisely. Computers tend not to. A while back, the British Library catalogue was put online as linked data. The library cataloguers had added details of author birth and death years but not always birth dates . But the data model normalised "1941" to "1941-01-01". (They fixed i…

> If I am digitising an old text of unknown origin, and on a page it says "January 12", and on the page after that it says "January 15", can I represent those with a reference to an implicit but unknown year? I don't know the year, but I do know that the January 12 instance comes before the January 15 instance on the next page. And at some future point, we might deduce from circumstantial evidence what year it was and the sequential ordering will still make sense. Relative dates would be useful here.

Of course, if the year is unknown, and could be before ~1918, and your dates are, say, the dates of two letters, you can't even be certain about the ordering of "January 12" and "January 15".

Re: Some Notes About Time

#65

Post by ccozan »

TeMPOraL wrote: post #33
masklinn wrote: post #7

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' 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…

Not even that; relativity doesn't allow a single special frame of reference. There's no such thing as universal "time elapsed since x". Putting the clock in space would be as arbitrary choice as putting it on my roof (albeit definitely more practical).

I think the one who solves this problem ( at least for humanity ) would get a Nobel.

After the humans will wander thru space ( at some time - very probable), there will no time reference, but only time intervals ( like, day on a spaceship has 24h , etc ). So in this case, you would measure 86400 seconds and call it a new day. No more leap seconds, etc.

Now the UNIX makes sense: count seconds since a certain event in time and meajure from there on, internally. Want to display it? Then use special computation to render it in the format ( read timezone, add relativistic skew, etc ).

Re: Some Notes About Time

#66

Post by Dylan16807 »

piqufoh wrote: post #62

"the Prime Meridian was (arbitrarily) chosen to pass through the Royal Observatory in Greenwich" At the International Meridian Conference in 1884 41 delegates from 25 nations met in Washington, D.C., USA and selected the meridian passing through Greenwich as the official prime meridian due to its popularity - not an arbitrary decision ;) However, the French abstained from the vote and French maps continued to use the…

How is a popularity contest not a shining ideal of completely arbitrary decision-making?

Re: Some Notes About Time

#67

Post by rmc »

tommorris wrote: post #51

Time is even more complicated than that because of vagueness, either intentional or unintentional. Humans represent time vaguely rather than precisely. Computers tend not to. A while back, the British Library catalogue was put online as linked data. The library cataloguers had added details of author birth and death years but not always birth dates . But the data model normalised "1941" to "1941-01-01". (They fixed i…

Eventually, we'll have an even better way of representing date-times that are more like bitmasks. We can then represent in a sane way the concept of opening hours. If you say the shop is open from 9am to 4:30pm Monday to Saturday, how do you do that?

For the record, the Open Street Map project has come up with a human readable way to encode opening hours. http://wiki.openstreetmap.org/wiki/Key:opening_hours

Re: Some Notes About Time

#68

Post by gnosis »

sla29970 wrote: post #52
albertzeyer wrote: post #28

This topic comes up again and again. But I mostly read only about the problems, not about the solutions. This post advises to use Unix timestamps. That's already what I'm doing mostly everywhere. And it seems to me like most people do and like this is somewhat accepted as the best available option - but still not perfect. Then I am wondering again: Isn't there really a perfect solution? Esp., the problems with Unix t…

Getting a TAI timestamp is impossible because the BIPM (the authority that defines TAI) does not want TAI used for such purposes. Without approval from the authority nobody will undertake to construct the technology to provide TAI to an operational system. Without a source for TAI, any system which claims to be using TAI is making the same mistake that POSIX made with UTC. To wit: Creating a new thing which has the n…

Why doesn't BIPM want TAI to be used for timestamps?

Re: Some Notes About Time

#69

Post by Dylan16807 »

btipling wrote: post #56
mmahemoff wrote: post #37

Formatting timestamps is a difficult decision for REST APIs to make. I polled my networks a while back and got pretty much divided responses [1]. In the end, I opted for milliseconds over ISO 8601 and I've been happy with that choice for ease of processing and debugging, especially as I'm now using the same values in the URL for caching purposes. 1. Google Plus conversation remains https://plus.google.com/10641309015…

Your API should return Unix time. The end.

Because when someone wants millisecond resolution the best answer is an integer number of seconds, right?

mmahemoff, are you using actual milliseconds, which means you have to keep track of leap seconds?

Re: Some Notes About Time

#70

Post by rmc »

martinced wrote: post #6
defrost wrote: 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…

Because, in many case, you really don't give a flying shit about the "real-world" time.

But there are loads of cases where your computer/programme needs to talk in "real-world" time. So you can't avoid the problem.

Post reply on HN