Natural language datetime parsing web API

http://www.timeapi.org/

by progrium • 17 years ago

27 21 17 years ago

lucifer• 17 years ago

http://www.timeapi.org/pdt/7+hours+before+tomorrow+at+noon http://www.timeapi.org/pdt/7+hours+before+noon+tomorrow

amoeba2• 17 years ago

This is a problem with Chronic and not with the webapp. It looks like Chronic doesn't understand the distinction between midnight and noon.

*Edit: Looks like a lot more is wrong with Chronic.

http://www.timeapi.org/pdt/seven%20hours%20before%20tomorrow

joe_the_user2• 17 years ago

The thing is that natural language processing can't be solved in pieces like this. Even a real human being doesn't understand discreet fragments of otherwise comprehensible human language. It is only by looking language as a whole that we human get the understanding, so spreading language processing out through a number of websites wouldn't work...

Plus this kind of "service" would be very fragile even the cases it would otherwise work...

catch232• 17 years ago

http://www.presdo.com has a much more powerful natural language time parser (that system handles all the timezones in the world) but they don't have a great api for extracting that info. It can't handle stuff like "seven hours before tomorrow" but it can do more common phrases like "tomorrow after lunch" or "day after tomorrow at 3pm"

JimmyL• 17 years ago

http://www.timeapi.org/est/92+days+from+now http://www.timeapi.org/est/3+months+from+now

While we're on the topic, anyone know of a clean Python library for converting local to UTC (that knows about DST)? For example, I'd like to specify a timezone, a local time, and a date, and get a UTC datetime.

In concrete terms, if I know that something is happening at 730pm four months from now in a city that's currently in EDT, suggestions on how to get a UTC for that?

DougBTX• 17 years ago

Well, I can't parse the first one, so I'm happy to let that one slip.

amoeba2• 17 years ago

Very cool. Noticed it doesn't always throw an error when it's sent nonsense:

http://www.timeapi.org/pdt/first+firday+this+september

Gave me the third Wednesday of this September.

fizx2• 17 years ago

Hey, you should use the date_range gem! (Shameless self-project pimping) Look at some of the things it adds to chronic:

http://github.com/fizx/date_range/blob/459812f091a67ce8d4b0e...

Edit: Oh, and you should add a batch api. Request latency will easily trump parsing time.

But yeah, keep up the good work. I need to find/create a good open web/api/scraping/big-data meetup, preferably in SF, not the valley.

byoung2• 17 years ago

http://www.timeapi.org/pdt/this+friday+at+lunchtime

by design?

tptacek3• 17 years ago

Uh...

    %w[ rubygems sinatra chronic ].each {|x| require x}
    get "/utc/:time" do |time|; Chronic.parse(time).to_s; end

(Also, Chronic is extremely slow).

pennig• 17 years ago

You've pretty much got the idea.

nir2• 17 years ago

Nothing wrong with that. Can be useful for non-Ruby apps, for example. BTW. A JSONP version could make usable from JavaScript..

perezd• 17 years ago

you should make one based off of my plugin smartmonth!

http://github.com/perezd/smart_month/tree/master

jwecker• 17 years ago

First thing I tried was "today"

Got back an internal server error, and then got back 1pm tomorrow (even with the correct timezone).

lucumo• 17 years ago

As much as everyone hates PHP, this would've been some two lines in it, using strtotime()

It's really one of the best functions in the language. http://nl2.php.net/manual/en/function.strtotime.php

Natural language datetime parsing web API

Related Stories