Hacker News API

  var time = new Date("") // in Javascript

  time = DateTime.iso8601("") # in Ruby

EDIT:

Changed DateTime.parse to DateTime.iso8601, to be even more retentive.

Look, parent claimed that parsing ISO strings is hard (it's not, especially if you're consuming a web api on a modern web language) and that it was more readable (which is so clearly wrong I have no words).

As for being more accurate, again no. The range is worse (lol wraparound if you're using a 32-bit int), there isn't explicit support for fractional seconds, doesn't map onto UTC cleanly, doesn't handle leap seconds, and so on.

It's only "easier" if you don't actually care about a human-readable timestamp that is robust and if you desire to do date parsing yourself instead of using any of the well-established libraries out there. Ugh.

On the one hand, of course it's great that HN is finally getting a proper API and also modernizing its markup (which is a mess even if you ignore all the tables – for example, the first paragraph in a comment usually isn't wrapped in

tags), but on the other hand this current v0 version is very lacking and impractical for a regular client application.

Since the top stories (limited to 100) and child comments are only available as a list of IDs a client app would have to make a separate HTTP request for every single item, which is obviously not something you'd want to do especially in a mobile environment. Other lists apart from the top stories (new, show, ask, best, active etc.) don't seem to be available at all right now.

Of course this is just the first version, and the documentation promises improvements over time – which I don't doubt at all – but there's no clear indication that the API will be at feature-parity with the current website, even excluding anything that requires authentication, by October 28. So this means that I – and other developers of client apps or unofficial APIs – will probably have to write new scraping code once the new rendering engine (which I assume refers to the website) arrives instead of being able to switch to the new API immediately.

Now I guess I might just be needlessly worried, especially since the blog post explicitly says that the new API "should hopefully making switching your apps fairly painless", but then why not wait until it's actually ready for that before making the announcement? Putting a half-baked API out there a few days/weeks (?) in advance before it's fully fleshed out doesn't seem all that helpful, at least to me.