Closed sircedriclex closed 5 years ago
I think at some point I'm just going to have to sit down and rewrite the parsing code. It tries too hard to be intuitive in edge cases, which makes it less predictable and therefore actually less intuitive for regular users.
This seems like a bug that might be fixable when I'm back from holidays.
That is by design, but right now I can't imagine why I thought it made sense to prefer "office hours" times even when starting the timer in the middle of the night. I think I would classify this as a bug also, and one of those "intuitive" cases that actually is not intuitive. :)
Have you had time to look into the first problem (hour 00 or 0 in combination with "until time of day")? It would be incredible if this could possibly get fixed in the next release. Thank you very much!
The first issue is now fixed in d715a5a845cd83d11bf12ff0af9a7c5c0e8c210f.
The second issue is now fixed in 85070fce0b221d37ea0b21e2ccba2a5015b2d397. Parsing something like until 1:15
will now be interpreted as until 1:15 am
when parsed at midnight and until 1:15 pm
when parsed at midday.
If you want a string to be parsed unconditionally as military time, you can suffix it with h
, hrs
, or hours
. For example, until 01:00 hours
will be interpreted as until 1:00 am
regardless of the current time.
Two issues have arisen regarding the input of 24-hour format in combination with "until time of day":
Maybe you can add a selectable option to generally use 24-hour format as default in combination with "until ..." if am/pm is not specified in the user input.
Thanks for the great program! I am using it on a daily basis.