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

51–60 of 118 posts

Re: Some Notes About Time

#51

Post by tommorris »

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 it after I moaned on Twitter.)

You should be able to represent in your data model, date-time library etc. vague dates and relative dates. When I say someone was born in 1941, I don't mean they are born at 1941-01-01T00:00:00Z. When I say that something happened on Thursday, I don't mean it happened at 2013-01-17T17:04:00Z. It may have happened at any time on Thursday.

If you store everything as Unix epoch seconds, good luck representing vagueness.

ISO 8601 gets around the problem rather neatly by being big-endian and allowing omission at any point. Wanna say 1941? "1941". Want to say January 1941? "1941-01". Want to say January 14, 1941? "1941-01-14". Want to get very detailed? You can add points of a second: "1941-01-14T12:14:03.0482Z". You can do timezones.

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?

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.

ISO 8601 allows you to represent ordinal dates (the number of days since the beginning of the calendar year).

Can your date-time representation deal with moveable feasts like Easter?

Have a look at the WHAT WG Wiki page on Time to see more obscure use cases: http://wiki.whatwg.org/wiki/Time

Your date-time representation, storage format and calculation libraries are probably inadequate.

Re: Some Notes About Time

#52

Post by sla29970 »

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 name of an existing thing but does not have the properties of the existing thing. This is a recipe for confusion.

Re: Some Notes About Time

#53

Post by albertzeyer »

sopooneo wrote: post #46
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…

I'm a noob. How can two equal timestamps represent different times? Or do you just mean as presented in different timezones?

See: http://en.wikipedia.org/wiki/Unix_time#Non-synchronous_Netwo...

The Unix timestamp 915148800 (from the table) represents two times (separated by one second from each other).

Re: Some Notes About Time

#54

Post by btipling »

I hate that Mixpanel and Google Analytics APIs return data in timezones, and the former doesn't tell you what the timezone is while the latter in v2 of their API can give you the wrong timezone.

Re: Some Notes About Time

#55

Post by ProblemFactory »

InclinedPlane wrote: post #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…

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

Definitely not. The only benefit of leap seconds is keeping UTC in sync with solar time: the sun is highest in the sky at 12:00 noon at Greenwich.

But in the modern world, synchronizing solar time and clocks to <1 minute is of no value to anyone but nostalgic astronomers.

Re: Some Notes About Time

#56

Post by btipling »

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.

Re: Some Notes About Time

#57

Post by ProblemFactory »

ArchD wrote: post #29
InclinedPlane wrote: post #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…

Since Unix time does NOT count the leap seconds, it allows the computation of the human-readable time from the Unix time without knowing when the leap seconds occurred. If knowledge of when the leap seconds occurred is required, then those events would need to be available somehow and used, introducing i) more expensive computation ii) difficulty in future-proofing an app since a reliable and updated data source supp…

The obvious solution would be to get rid of leap seconds entirely, and let UTC and solar time (when sun is highest at Greenwich) drift apart.

Sun rising 30 seconds later every century is not really a problem in my opinion.

Re: Some Notes About Time

#58

Post by haberman »

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…

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

Your claim that using Unix Time saves you from worrying about leap seconds is incorrect. Unix Time goes backwards when a leap second occurs, which can screw up a lot of software. Check out Google's solution to the problem, which is to "smear" the leap second over a period of time before it actually occurs: http://googleblog.blogspot.in/2011/09/time-technology-and-le...

Practically no software uses true seconds since the epoch; if it did then simple operations like turning an epoch time into a calendar date would require consulting a table of leap seconds, and would give up the invariant that every day is exactly 86,400 seconds. Whether this was the right decision or not is debatable, but it is a mistake to think that using Unix Time saves you from all weirdness surrounding civil time.

Re: Some Notes About Time

#60

Post by mbq »

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.
Post reply on HN