Re:Show HN: Durat.io
by edraferi on Monday July 13, 2015 @11:03AM
(#9878521)
You could bring this to a wider audience by integrating it with DuckDuckGo. You can arrange for DDG to send appropriate queries to your service with Spice [0].
If you don't want to handle the traffic, you can program an instant answer that runs on the DDG servers. Right now they have separate modules for time zone conversion [1], unit conversion [2] and uptime calculation [3]. Durat.io appears to hit a much wider set of use cases.
Re:Show HN: Durat.io
by strictfp on Monday July 13, 2015 @05:51AM
(#9877164)
Author here. I built this primarily to perform time-sheet calculations and to figure out what time it is in different cities easily when talking to friends overseas.
The site is the culmination of my experimentation with parsers, and specifically my last little Java TDOP parser library bychan (https://github.com/atorstling/bychan).
Please criticize / ask any questions and/or suggest anything below.
Re:Show HN: Durat.io
by acqq on Monday July 13, 2015 @08:35AM
(#9877714)
Looks OK.
Now looking at the examples, the answer for "now in zone Lisbon" gives
2015-07-13T13:31:47.968+01:00[Europe/Lisbon]
Why not just "today, 14:31:47, Lisbon"? If I enter the expression I don't actually like receiving the expression as the answer. Also, the whole "expression" of the translation of the question is displayed, when most probably the user doesn't need it every time, and then it's initially confusing.
Re:Show HN: Durat.io
by strictfp on Monday July 13, 2015 @12:25PM
(#9879112)
Duratio actually kinda adresses this for time instants. If you enter "now" you get an instant. You can move it around the time axis and show its value at a specific zone by using "in zone PST" or similar. So if you enter "now PST" the timezone is considered redundant information and you get an error. But if you say "2013-01-10 PST" it parses. The conversion can be performed by entering "2013-01-10 pst in zone cet".
"today" and similar expressions are calculated in CET. I was considering customizing this or adding syntax for it, but it was de-scoped for the initial release.
Re:Show HN: Durat.io
by acqq on Monday July 13, 2015 @09:25AM
(#9877922)
I agree, it can be confusing too. At least as long as the "today" is the same on both places, it's clear. I'd keep the full date when it's not today on both places.
Re:Show HN: Durat.io
by strictfp on Monday July 13, 2015 @09:02AM
(#9877814)
Thanks for your feedback. I agree that the representation is suboptimal. I will work on this if there is interest in the site. Regarding the ast representation, I will think about making it optional.
Re:Show HN: Durat.io
by strictfp on Monday July 13, 2015 @05:26AM
(#9877100)
Thanks for the QA! I haven't put all to much time into weeding out all the bugs yet. If the site gets popular that will definitely change.
edit: The first bug is a showstopper. Everything is supposed to be a bigint, so this will be fixed ASAP. The second one I will catch and print a nicer error for. The third one I will have to look into. I probably perform the calculation incorrectly by using the wrong temporal types. Thanks again.
Re:Show HN: Durat.io
by JoshTriplett on Monday July 13, 2015 @05:37AM
(#9877129)
The third one is the hardest to deal with:
~$ cal 9 1752
September 1752
Su Mo Tu We Th Fr Sa
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
This isn't the only bit of craziness you'd need to deal with if you wanted to handle historical times perfectly. For instance, consider attempting to get an accurate duration in hours of a time that extends across the daylight savings time switchover, historically, in a region where that has changed from year to year.
Another interesting one: 2015-07-01 - 2015-06-29 returns "PT48H", but it should be 48 hours and 1 second.
Re:Show HN: Durat.io
by strictfp on Monday July 13, 2015 @05:41AM
(#9877137)
I'm currently passing on all the date calculations to the java.time API, so at least I won't have to do it all on my own. But it's sometimes a challenge to even pass it down the right way will all the different use-cases and temporal types available.
Re:Show HN: Durat.io
by strictfp on Monday July 13, 2015 @06:09AM
(#9877196)
My NLP is not top notch :D. I figured that getting the parsing intuitive would be doable given the relatively narrow field, but I was proven wrong :) The result is that you need to learn the syntax a bit before it feels intuitive.
Regarding your specific examples: You need "in _zone_ new york" ATM. I think 'weeks' is missing simply as the result of an oversight :/ Thanks for the QA.
Re:Show HN: Durat.io
by mtourne on Monday July 13, 2015 @02:41PM
(#9880079)
I've been using Soulver on mac which does a lot of similar unit calculations, conversions etc.
Works with time (but maybe not as advanced) and a lot of other things.
If you don't want to handle the traffic, you can program an instant answer that runs on the DDG servers. Right now they have separate modules for time zone conversion [1], unit conversion [2] and uptime calculation [3]. Durat.io appears to hit a much wider set of use cases.
[0] https://duck.co/duckduckhack/spice_overview [1] https://duck.co/ia/view/timezone_converter [2] https://duck.co/ia/view/conversions [3] https://duck.co/ia/view/uptime
The site is the culmination of my experimentation with parsers, and specifically my last little Java TDOP parser library bychan (https://github.com/atorstling/bychan).
Please criticize / ask any questions and/or suggest anything below.
Now looking at the examples, the answer for "now in zone Lisbon" gives
2015-07-13T13:31:47.968+01:00[Europe/Lisbon]
Why not just "today, 14:31:47, Lisbon"? If I enter the expression I don't actually like receiving the expression as the answer. Also, the whole "expression" of the translation of the question is displayed, when most probably the user doesn't need it every time, and then it's initially confusing.
BTW: what does "today" mean when your wall clock shows e.g. 23:25:00? Is it "today in Lisbon" or "today at your timezone"?
"today" and similar expressions are calculated in CET. I was considering customizing this or adding syntax for it, but it was de-scoped for the initial release.
And do you prefer the current:
2015-07-13T13:31:47.968+01:00[Europe/Lisbon]
or something simpler?
Is this irony?
Probably not. Nothing is ever irony.
"2 weeks ago on Friday at 13:45"
"Saturday Christmas 2010 at noon"
http://search.cpan.org/~sbeck/Date-Manip-6.50/lib/Date/Manip...
Remember to sanitize your input. http://durat.io/?q=%22/%3E%3Cscript%3Ealert(1);%3C/script%3E
The query "9999-99-99" throws java.time.format.DateTimeParseException (http://durat.io/?q=9999-99-99).
The query "2147483647 days + 1 day" throws java.lang.ArithmeticException (http://durat.io/?q=2147483647+days+%2B+1+day)
The query "1752-09-14 - 1752-09-02" returns PT288H, but arguably it should return PT24H (http://durat.io/?q=1752-09-14+-+1752-09-02, see also: https://en.wikipedia.org/wiki/Cal_(Unix)#Features)
edit: The first bug is a showstopper. Everything is supposed to be a bigint, so this will be fixed ASAP. The second one I will catch and print a nicer error for. The third one I will have to look into. I probably perform the calculation incorrectly by using the wrong temporal types. Thanks again.
Another interesting one: 2015-07-01 - 2015-06-29 returns "PT48H", but it should be 48 hours and 1 second.
http://durat.io/?q=%22%20/%3E%3Cscript%3Ealert(1)%3C/script%...
edit: After doing some quick testing, Wolfram doesn't seem very good at time zone conversions or time span conversions.
I suppose, I doesn't understand my accent ;)
Regarding your specific examples: You need "in _zone_ new york" ATM. I think 'weeks' is missing simply as the result of an oversight :/ Thanks for the QA.
>> now
== 13-Jul-2015/11:46:45+3:00
>> now + 4:15
== 13-Jul-2015/16:01:52+3:00
> 8:30am + 2.5 hours = PT11H