Open Nanosync opened 4 years ago
This issue is due to an attempt to allow more natural forms of date and time input by integrating Natty and paticularly the limitations of the natural language processing used by Natty. Natty attempts to parse anything a user enters that resembles a valid date as a date. This results in unexpected date time when the representation of the date a user enters does not align with Natty's expectations.
Natty attempts to recognize a wide range of date formats, but since there is an inherent ambiguity in the grammar describing these formats, some decisions need to be made arbitrarily.
Excerpt from Natty's documentation available here
As language is naturally ambiguous in the absence of context, and stronger natural language processing to determine said context, it is not feasible to correctly parse every single date that a user enters.
For example:
Attempting to parse 33
alone is ambiguous. 33/2
is less ambiguous, however, this format does no align with most common time inputs, and the date is also not a valid date. However, Natty is not aware of the context of this input and tries its best to determine what it could mean. This results in it parsing a time rather than a date as 33 is not a valid date in any context. This results in the outcome seen where Natty parses the 2
in the input an an hour rather than a month due to the absence of a valid date, since in most contexts 2
is taken to be a time.
For this particular case:
As stated in our user guide, users ‘can refer to http://natty.joestelmach.com/ for documentation and more information’. As seen from the ‘try it out’ section of the aforementioned website, Natty successfully parses a datetime input of ‘nov 32 2019’ as 1st Nov. This matches the success message in the screenshot of the bug report (1 Nov). The time field of the added budget in the report (12:00:00 AM) is an intended budget feature.
Hence, we are changing the bug type to a FeatureFlaw
:
type.FunctionalityBug
: A functionality does not work as specified/expected.
Downgrading severity to Low
:
High
severity issue. Additionally, in normal usage, users would not want to enter an invalid date when tracking their expenses, and this situation would only really occur with a typo that results in a date being unintelligible or when someone is attempting to purposefully achieve unexpected outputs of the natural language date parser.We are defining this issue as not in scope for the following reasons:
This issue is mostly due to the limitations of the 3rd party library Natty, and due to our lack of knowledge regarding natural language processing. This behaviour is inherited from the 3rd party library.
Given that there is no rigid date format and natural language processing is used, there is also no way to judge that an input which may be ambiguous is parsed exactly as the user intended. As such, I feel that this should not be blamed on the team.
Team chose [response.NotInScope
]
Reason for disagreement: Thank you for the response.
According to the User Guide, the team has modified the natural language parser to read dates as dd/MM.
This has led me to believe that the team is talented - they are highly capable in modifying the third-party library's behaviour and validating additional inputs passed to Natty since the input format was changed.
Even if there are no rigid date formats, it should still be mentioned in the user guide as a tip that invalid dates that are entered may not show an error message. In the best case scenario, an error message can be shown.
Thus, I believe that this issue is still in scope.
Team chose [severity.Low
].
Originally [severity.Medium
].
Reason for disagreement:
Team chose [type.FeatureFlaw
].
Originally [type.FunctionalityBug
].
Reason for disagreement:
Reason: Users might incorrectly key in the date and the app should prompt the user of invalid input.
Steps to reproduce:
33 nov
as end date is parsed as a valid input