Entering Date Due Issue - truncating/rounding minutes
markwilliams says:
Used to be able to enter a time for a task that would be due the next day as 1130am and it would set the date and time as December 16, 2011 11:30 AM.
Now that same entry of 1130am is being entered as December 16, 2011 11:00 AM
Is there any fix for this? Other than explicitly typing in "11:30 AM"?
I would prefer not to enter that unnecessary colon.
Now that same entry of 1130am is being entered as December 16, 2011 11:00 AM
Is there any fix for this? Other than explicitly typing in "11:30 AM"?
I would prefer not to enter that unnecessary colon.
markwilliams says:
This is a somewhat recent change though as in the past 1130 would resolve correctly to 11:30 AM.
Can't pin point when it changed.
Can't pin point when it changed.
markwilliams says:
Here's more strangeness with this. I entered a new task yesterday that I intended to be due at 4:45 pm today. I entered the due date as 445 tomorrow. It resolved the time to 4:05 pm.
When editing the task:
If I enter "445" it is due at 4:05 AM
If I enter "445 pm" it is due at 4:05 PM
If I enter "1645" it is due at 4:05 PM
If I enter "4:45 pm" it is due at 4:45 PM
So Smart Add can correctly determine that any of those entries are a time (without entering a colon) . . . but why is it now setting itself to 5 after the hour unless a colon is entered?
Before it would set it to be due on the hour and drop the minutes, which annoying was at least somewhat more logical.
When editing the task:
If I enter "445" it is due at 4:05 AM
If I enter "445 pm" it is due at 4:05 PM
If I enter "1645" it is due at 4:05 PM
If I enter "4:45 pm" it is due at 4:45 PM
So Smart Add can correctly determine that any of those entries are a time (without entering a colon) . . . but why is it now setting itself to 5 after the hour unless a colon is entered?
Before it would set it to be due on the hour and drop the minutes, which annoying was at least somewhat more logical.
andrewski (Remember The Milk) says:
Hi markwilliams12,
Thanks for those details; I've added them to our list to investigate. In the meantime, as Brendan mentioned, times with a colon should always be parsed correctly.
Thanks for those details; I've added them to our list to investigate. In the meantime, as Brendan mentioned, times with a colon should always be parsed correctly.