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

Show HN: Duckling – Open-source datetime expression parsing

duckling-lib.org

Post reply on HN
Print view View original

51–60 of 70 posts

Re: Show HN: Duckling – Open-source datetime expression parsing

#51

Post by peterwwillis »

Perl modules to implement this would be Date::Manip and DateTime::Format::Natural. To see some funnier modules (like calculating Discordian dates or Japanese eras) look here: http://www.perl.com/pub/2003/03/13/datetime.html

I actually bumped up against legacy time/date issues while working on SSL cert parsing. An old Perl interpreter's 32-bit limits kept resetting my dates! Rather than upgrade perl or my architecture, I wrote my own perl methods to calculate infinite time (sorta?) on 32-bit systems with old perls.

For those that haven't worked with date parsing before: timezones are surprisingly complex, leap years are stupid, daylight savings is really stupid, and leap seconds are impossible without a regularly updated leap second database (similar to timezones, but worse). (The math to calculate dates correctly is rather simple, but you need to be pretty good at math to optimize it) https://github.com/psypete/public-bin/blob/public-bin/src/ne...

Re: Show HN: Duckling – Open-source datetime expression parsing

#52

Post by kibwen »

ar7hur wrote: post #7
zongitsrinzler wrote: post #4

This if off topic but how much does Wit use Clojure?

Probably too much :) All our backend is Clojure, all our new web developments are in ClojureScript (with React and Om). The only places we're not using Clojure are iOS, Android and Raspberry/embedded linux. We're using Rust more and more for the latter.

I'd love to hear about your experiences using Rust on embedded devices, and I know the Rust devteam would as well.

Re: Show HN: Duckling – Open-source datetime expression parsing

#53

Post by Someone »

dangerlibrary wrote: post #5

hah! 1/2/2014 is January 2nd. Take that, Europeans. Unless you are checking my IP address to guess the best convention...

Are there countries that use slashes for d/m/y?

What surprised me was "1-2-2014":

  From Thursday, 2 October 2014 at 1:02:00 +0000 (UTC)
  to Wednesday, 1 January 2014 at 0:00:00 +0000 (UTC)
On top of the "where did it get those timestamps from", time flows backwards in that interval.

Re: Show HN: Duckling – Open-source datetime expression parsing

#55

Post by EyeballKid »

Someone wrote: post #53
dangerlibrary wrote: post #5

hah! 1/2/2014 is January 2nd. Take that, Europeans. Unless you are checking my IP address to guess the best convention...

Are there countries that use slashes for d/m/y? What surprised me was "1-2-2014": From Thursday, 2 October 2014 at 1:02:00 +0000 (UTC) to Wednesday, 1 January 2014 at 0:00:00 +0000 (UTC) On top of the "where did it get those timestamps from", time flows backwards in that interval.

> Are there countries that use slashes for d/m/y?

Oh yes, loads of them. Lots more than use m/d/y anyway. See https://en.wikipedia.org/wiki/Date_format_by_country

Canada looks the most hellish, eg: "Immigration Canada Stamps use DD/MM/YYYY and Canada Customs Stamps use MM/DD/YYYY." eek!

Re: Show HN: Duckling – Open-source datetime expression parsing

#56

Post by hamburglar »

Suggestion: if you want people using the demo page to be able to spot errors easily, it would be useful to give a plain english description of when the time they specified is. For example, if I enter "quarter of six", you could parse it in my local timezone and spit back a piece of text like, "that is a little more than 2 hours from now, or: Thursday, 2 October 2014 at 17:45:00 -0700 (PST)".

Re: Show HN: Duckling – Open-source datetime expression parsing

#57

Post by ar7hur »

aleem wrote: post #31

One suggestion from a use-case standpoint. On iOS, "tomorrow at 6" is parsed as 6PM instead of 6AM. This makes sense because usually people really mean 6PM. This is context dependent--in chat logs etc this is desirable. Semantically speaking, the Duckling library does the right thing by parsing it at 6AM, but if the goal is ultimately to parse human expressions, then the iOS approach is probably better. EDIT: Another…

We just updated the demo. Now you can try "see you tomorrow evening at 6" and see the partial parse.

Re: Show HN: Duckling – Open-source datetime expression parsing

#58

Post by ar7hur »

blandinw wrote: post #34
krammer wrote: post #30

Wow, we've tried to solve this problem inhouse and our results are much worse than this. One question, how hard is to detect that kind of expresions inside a random text? Like gmail does for suggesting a calendar appoinment within an email.

Even though the demo website expects the whole input to be a time expression, Duckling actually detects substrings inside a larger block of text. We've mostly used it on short sentences, but it should work on larger inputs, like articles. I'd recommend splitting very large inputs into sentences though.

Demo site updated, now shows partial parses.

Re: Show HN: Duckling – Open-source datetime expression parsing

#59

Post by ar7hur »

kibwen wrote: post #52
ar7hur wrote: post #7

Earlier quoted context omitted.

Probably too much :) All our backend is Clojure, all our new web developments are in ClojureScript (with React and Om). The only places we're not using Clojure are iOS, Android and Raspberry/embedded linux. We're using Rust more and more for the latter.

I'd love to hear about your experiences using Rust on embedded devices, and I know the Rust devteam would as well.

This is our first experiment with Rust on Raspberry Pi: https://wit.ai/blog/2014/09/12/office-automation-with-raspbe...

We'll share more as we progress.

Post reply on HN