Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

at flag should use today's date #91

Open
phantomwhale opened this issue Mar 19, 2014 · 2 comments
Open

at flag should use today's date #91

phantomwhale opened this issue Mar 19, 2014 · 2 comments
Labels
in consideration Describes a feature worth taking into account

Comments

@phantomwhale
Copy link

This evening, I realised I forgot to track a couple of hours in the morning on an ongoing project, so typed

t resume -a 08:15
t out -a 10:15

But this added them as entries for TOMORROW morning ? Any reason why it does this, rather than use today's date ?

@samg
Copy link
Owner

samg commented Apr 6, 2014

I believe the current behavior is to choose the time closest to the current time when there's ambiguity (e.g. if it's 9:15pm choose 10:15pm one hour in the future instead of 10:15am 11 hours in the past). For cases where this isn't the desired behavior you'd need to be more explicit (e.g. "today 10:15 am")

See https://github.com/samg/timetrap/blob/master/lib/timetrap/timer.rb#L34-L39 for the spot this is implemented.

Let me know if this isn't the behavior you're observing or if you have suggestions on how to improve it.

@phantomwhale
Copy link
Author

I guess I personally expected it to use today's date, by default, no matter what time I entered.

I also thought I entered those times I gave above late in the evening (around midnight), so would have thought they would have gone back 2-4 hours, rather than forward 8-10 hours from what you are suggesting ? But it was a while ago, so I cannot be sure if that's exactly what happened.

I've learned the ways of specifiying date and AM/PM now, so it's less of an issue as I get more comfortable with the tool, but from my perspective (and I understand it's just MY perspective !) the expectation above was the "least surprising" behavior

@categulario categulario added the in consideration Describes a feature worth taking into account label May 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in consideration Describes a feature worth taking into account
Projects
None yet
Development

No branches or pull requests

3 participants