Closed wulftone closed 11 years ago
Interesting edge case.
It looks like this is a subtle interaction between a bug in Chronic and some fanciness we attempt to do in Timetrap. When Timetrap passes your date on to Chronic it tries to make sure that Chronic hands back a time that makes sense. It does this by toggling Chronic.parse
's :context
option and picking the returned time that is closest to now. https://github.com/samg/timetrap/blob/master/lib/timetrap/timer.rb#L32-L37
There's some good reason it does this which I can't fully recall at the moment. I think it helps with certain edge cases where you'd get illogical end times with ambiguous times (e.g. I check out at "noon" and Chronic assumes I mean noon tomorrow instead of noon 2 hours ago).
In this case the time you're passing isn't ambiguous so it appears to be a bug in Chronic that it's returning a time from 9/24 when the context is set to :past
.
The good news is this seems to be fixed in Chronic v0.10. Running gem install chronic
seems to fix the problem. I'll bump the minimum version of Chronic which Timetrap requires asap.
Let me know if upgrading to the latest Chronic version fixes the issue for you as well.
Thanks!
Awesome, that seems to have fixed it, although I had to use the specific_install
gem to install the master branch of timetrap from github. Thanks!
I'm filling out a schedule and ran into this bit of crazy:
Not sure why, because Chronic appears to be parsing correctly...
EDIT: It occurs to me that timetrap must be comparing it to the current datetime, so it's getting strange negative values for future dates. Not sure if this is something you want to support. : /