4 ms·

Natural language datetime parsing web API

27 points by progrium 17y ago

lucifer 17y ago
http://www.timeapi.org/pdt/7+hours+before+tomorrow+at+noon http://www.timeapi.org/pdt/7+hours+before+tomorrow+at+noon http://www.timeapi.org/pdt/7+hours+before+noon+tomorrow http://www.timeapi.org/pdt/7+hours+before+noon+tomorrow
- amoeba 17y 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 http://www.timeapi.org/pdt/seven%20hours%20before%20tomorrow
  - joe_the_user 17y 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...
  - catch23 17y ago
    http://www.presdo.com 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"
    - joe_the_user 17y ago
      day after tomorrow at 3pm Lol, even I would be thrown by that phrase... (a comma might help) It's like SQL. The problem with SQL isn't that simple SQL phrases are that different from normal language OR that complex SQL phrases break the rules of simple SQL phrases. The problem with SQL is that humans beings have a lot of trouble understanding complex phrases that follow the most consistent possible rules followed by simple phrases... So clever NLP often just out-clevers itself communicating with us... (remember SQL was originally intended to be a language usable by even non-programmers and ended up being a language that even many programmers feared ... though I have an unusual fondness for it).
    - catch23 17y ago
      Also, it handles time ranges, subject, verb, multiple time selections, and timezones of the person you're scheduling with. I've been using it for a long time already and it's pretty good at handling crazy stuff like: "Meet with sam@gmail.com and jim@gmail.com next wednesday from 3pm to 9pm or first thursday of next month from 4pm to 8pm" This creates an event that allows sam & jim to choose between these 2 dates. If presdo had an api to extract this information, I'd be on board!
- JimmyL 17y ago
  http://www.timeapi.org/est/92+days+from+now http://www.timeapi.org/est/92+days+from+now http://www.timeapi.org/est/3+months+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 17y ago
  Well, I can't parse the first one, so I'm happy to let that one slip.
amoeba 17y 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 http://www.timeapi.org/pdt/first+firday+this+september Gave me the third Wednesday of this September.
officiallyrad 17y ago
Very cool, anyone know one for PHP?
perezd 17y ago
you should make one based off of my plugin smartmonth! http://github.com/perezd/smart_month/tree/master http://github.com/perezd/smart_month/tree/master
fizx 17y 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/459812f091a67ce8d4b0e737282f4712b9cdd59a/spec/date_range_spec.rb 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 17y ago
http://www.timeapi.org/pdt/this+friday+at+lunchtime http://www.timeapi.org/pdt/this+friday+at+lunchtime by design?
tptacek 17y 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 17y ago
  You've pretty much got the idea.
  - nir 17y ago
    Nothing wrong with that. Can be useful for non-Ruby apps, for example. BTW. A JSONP version could make usable from JavaScript..
    - tptacek 17y ago
      It's already usable from JS. $.get("/time-thingy/utc/" + whatever, function(date) { alert("your UTC timestamp is " + date); }); Not to be snarky, though, but this seems pretty silly. What major web framework doesn't have natural-language date parsing? There are BSD-licensed C libraries that do it. Why remote that?
      - nir 17y ago
        I was thinking more as a web service, so JSONP is for cross site XHR. I assume someone would not have a good NL date parser for their environment, or won't be able to run it for some reason, or would simply prefer Chronic. A lot of stuff that seems pointless ends up being useful, and vice versa. Assuming it's on Heroku's free plan, it costs nothing to run forever, so why not? If it helps 10 people, it already beat most web pages.
      - fizx 17y ago
        Pointers to the C libraries, please! (beyond GNU Getdate, which doesn't really do this.)
        17y ago
jwecker 17y 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 17y 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 http://nl2.php.net/manual/en/function.strtotime.php

27 points by progrium 17y ago

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

amoeba 17y 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 http://www.timeapi.org/pdt/seven%20hours%20before%20tomorrow
- joe_the_user 17y 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...
- catch23 17y ago
  http://www.presdo.com 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"
  - joe_the_user 17y ago
    day after tomorrow at 3pm Lol, even I would be thrown by that phrase... (a comma might help) It's like SQL. The problem with SQL isn't that simple SQL phrases are that different from normal language OR that complex SQL phrases break the rules of simple SQL phrases. The problem with SQL is that humans beings have a lot of trouble understanding complex phrases that follow the most consistent possible rules followed by simple phrases... So clever NLP often just out-clevers itself communicating with us... (remember SQL was originally intended to be a language usable by even non-programmers and ended up being a language that even many programmers feared ... though I have an unusual fondness for it).
  - catch23 17y ago
    Also, it handles time ranges, subject, verb, multiple time selections, and timezones of the person you're scheduling with. I've been using it for a long time already and it's pretty good at handling crazy stuff like: "Meet with sam@gmail.com and jim@gmail.com next wednesday from 3pm to 9pm or first thursday of next month from 4pm to 8pm" This creates an event that allows sam & jim to choose between these 2 dates. If presdo had an api to extract this information, I'd be on board!
JimmyL 17y ago
http://www.timeapi.org/est/92+days+from+now http://www.timeapi.org/est/92+days+from+now http://www.timeapi.org/est/3+months+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 17y ago
Well, I can't parse the first one, so I'm happy to let that one slip.

amoeba 17y 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 http://www.timeapi.org/pdt/first+firday+this+september Gave me the third Wednesday of this September.

officiallyrad 17y ago

Very cool, anyone know one for PHP?

perezd 17y ago

you should make one based off of my plugin smartmonth! http://github.com/perezd/smart_month/tree/master http://github.com/perezd/smart_month/tree/master

fizx 17y 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/459812f091a67ce8d4b0e737282f4712b9cdd59a/spec/date_range_spec.rb 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 17y ago

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

tptacek 17y 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 17y ago
You've pretty much got the idea.
- nir 17y ago
  Nothing wrong with that. Can be useful for non-Ruby apps, for example. BTW. A JSONP version could make usable from JavaScript..
  - tptacek 17y ago
    It's already usable from JS. $.get("/time-thingy/utc/" + whatever, function(date) { alert("your UTC timestamp is " + date); }); Not to be snarky, though, but this seems pretty silly. What major web framework doesn't have natural-language date parsing? There are BSD-licensed C libraries that do it. Why remote that?
    - nir 17y ago
      I was thinking more as a web service, so JSONP is for cross site XHR. I assume someone would not have a good NL date parser for their environment, or won't be able to run it for some reason, or would simply prefer Chronic. A lot of stuff that seems pointless ends up being useful, and vice versa. Assuming it's on Heroku's free plan, it costs nothing to run forever, so why not? If it helps 10 people, it already beat most web pages.
    - fizx 17y ago
      Pointers to the C libraries, please! (beyond GNU Getdate, which doesn't really do this.)
      - 17y ago

jwecker 17y 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 17y 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 http://nl2.php.net/manual/en/function.strtotime.php