Due date parsing is too aggressive and causes other issues with list entries #1994
Frontend Version: 0.20.0
API Version: 0.20.0
Browser and OS Version: Firefox 106.0.3
Steps to reproduce:
- Create a new entry in a list with a fraction, e.g., "2 1/2 inch pocket screws"
- The entry has parsed the fraction "1/2" as January 2 and replaces my text with "2 inch pocket screws" (consequently, this is the absolute wrong thing to add to my list)
- Edit the entry to add back in the fraction and hit "Save".
- The entry has not updated in the original list. You need to refresh the entire page to see the updated entry.
Integers with fractions should not be misinterpretted as dates when there are no prepositions indicating so.
The entry should not have removed my fraction
Updating the entry title back to the correct measurement should update the original item in the list without needing to refresh the page.
The entry was entered incorrectly due to an overly aggressive date time parser
A due date was incorrectly applied to my entry
Updating the title of the entry and hitting "Save" did not update the title in the list.
- I have provided all required information
- I am using the latest release or the latest unstable build
- I was able to reproduce the bug on try
How are you editing the task? This seems to work fine for me on try.
Integers with fractions should not be misinterpretted as dates when there are no prepositions indicating so
What would be such a preposition?
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?