A couple of issues relating to manual due date input (the picker's fine):
A couple of issues relating to manual due date input (the picker's fine):
1. I'm a bit puzzled by the format. The manual seems to suggest both dd/mm/yyyy and mm/dd/yyyy work. The former seems to win in case of ambiguity. But an attempted dd/mm/yy gets interpreted as yy/mm/dd.
I find this confusing enough that whenever I manually enter a date I have to check after what date it turned out to be. Any chance of pinning to one (preferably user-chosen) format, and refusing to accept bad input?
2. Relatedly, invalid date input (eg. 45/45/45) results in a 'due date was updated' message, but any due date is removed. I think I'd call that a bug, or at least ambiguous feedback ;)
1. I'm a bit puzzled by the format. The manual seems to suggest both dd/mm/yyyy and mm/dd/yyyy work. The former seems to win in case of ambiguity. But an attempted dd/mm/yy gets interpreted as yy/mm/dd.
I find this confusing enough that whenever I manually enter a date I have to check after what date it turned out to be. Any chance of pinning to one (preferably user-chosen) format, and refusing to accept bad input?
2. Relatedly, invalid date input (eg. 45/45/45) results in a 'due date was updated' message, but any due date is removed. I think I'd call that a bug, or at least ambiguous feedback ;)
Hello, could you please give a specific example when dd/mm/yy gets interpreted as yy/mm/dd?
ReplyDeleteAs for invalid input - I agree that this is a bug, will add it to our buglist.
Thanks for the feedback!
An example would be 01/01/16, which gets interpreted as Jan 16 2001. I think it's the same with any attempt at a 2-digit year.
ReplyDeleteThat's interesting. In my browser such a date is interpreted correctly, as 01.01.2016. Which browser do you use? What timezone you're in?
ReplyDeleteThat was Safari, but I've just tried it in Chrome with the same result (both on a mac). Timezone is AEST (gmt + 11 currently).
ReplyDeleteThanks, will try to fix this.
ReplyDelete