junnbang
commented
5 years ago 
Open junnbang opened 5 years ago
junnbang
commented
5 years ago
nus-pe-bot
commented
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: [replace this with your reason]
Team chose [severity.Low].
Originally [severity.High].
Reason for disagreement: [replace this with your reason]
Team chose [type.FeatureFlaw].
Originally [type.FunctionalityBug].
Reason for disagreement: [replace this with your reason]