search

samg / timetrap

Simple command line timetracker
http://rubygems.org/gems/timetrap
Other
1.48k stars 116 forks source link

Strange behavior when adding future entries #74

Closed wulftone closed 11 years ago

wulftone commented 11 years ago

I'm filling out a schedule and ran into this bit of crazy:

$ t i -a "2013-09-25 11:00"
Checked into sheet "Invoice".
$ t o -a "2013-09-25 19:00"
Checked out of sheet "Invoice".
$ t d
Timesheet: Invoice
    Day                Start      End        Duration   Notes
    Mon Aug 19, 2013   11:00:00 - 19:00:00   8:00:00    
                                             8:00:00
    Wed Sep 25, 2013   11:00:00 - 19:00:00 -16:00:00    
                                           -16:00:00
    ---------------------------------------------------------
    Total                                   -8:00:00
$ t e -e "2013-09-25 12:00"
Editing last entry you checked out of

Timesheet: Invoice
    Day                Start      End        Duration   Notes
    Wed Sep 25, 2013   11:00:00 - 12:00:00   1:00:00    
                                             1:00:00
    ---------------------------------------------------------
    Total                                    1:00:00
$ t e -e "2013-09-25 13:00"
Editing last entry you checked out of

Timesheet: Invoice
    Day                Start      End        Duration   Notes
    Wed Sep 25, 2013   11:00:00 - 13:00:00 -22:00:00    
                                           -22:00:00
    ---------------------------------------------------------
    Total                                  -22:00:00
$ irb
2.0.0p247 :001 > require 'chronic'
true
2.0.0p247 :002 > Chronic.parse "2013-09-25 11:00"
2013-09-25 11:00:00 -0700
2.0.0p247 :003 > Chronic.parse "2013-09-25 11:00"
2013-09-25 11:00:00 -0700
2.0.0p247 :004 > Chronic.parse "2013-09-25 12:00"
2013-09-25 12:00:00 -0700
2.0.0p247 :005 > Chronic.parse "2013-09-25 13:00"
2013-09-25 13:00:00 -0700

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. : /

samg commented 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!

wulftone commented 11 years ago

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!