search

nus-cs2103-AY2122S2 / forum

13 stars 1 forks source link

Datetime boundary #260

Closed Jacky142857 closed 2 years ago

Jacky142857 commented 2 years ago

Clearly, java LocalDatetime want people to have a smoother user experience that for the boundary value near a month, if you entered a invalid value, e.g. 31 April, it will still be accepted and modified to 30th April when being parsed, and 29th Feb being parsed to 28th Feb.

Almost every team using those libraries is encountering this issue.

Yes, it can be viewed as a bug. But in my most honest opinion, it is a smart design that prevents you from checking leap year and prevents you from you from remembering how many days are in this month.

I think many people believe in the same way. However, in the actual PE, this will still be reported as a bug, no matter how well you justify. Welcome everyone to discuss about this issue.

domlimm commented 2 years ago

+1 on this. My team has this issue too and was brought up during PE-D.

damithc commented 2 years ago

Clearly, java LocalDatetime want people to have a smoother user experience that for the boundary value near a month, if you entered a invalid value, e.g. 31 April, it will still be accepted and modified to 30th April when being parsed, and 29th Feb being parsed to 28th Feb.

Interesting. I remember a natural date parser library (Natty?) that used to auto-convert Feb 29th to March 1st instead. Looks like LocalDatetime took a different approach.

Still, we can't assume users will be aware of this behavior.

  1. Ideal: detect and warn the user when this happens because we can't be sure if the auto-converted date is the same as the date the user intended. But if you haven't done that already, it's too late to do it now. EDIT: may be OK to fix. See https://github.com/nus-cs2103-AY2122S2/forum/issues/260#issuecomment-1091193706
  2. Acceptable: mention this behavior in the UG. That can be allowed as there is no restriction on documentation updates.
bingsen0806 commented 2 years ago

My team has this issue previously as well. For your information I'm also using Java libraries for Date but we managed to fixed this issue (now if 31st April is input our system knows that it's invalid).

My personal opinion is that you shouldn't use "smart clock" as an excuse to cover up bugs that you cannot fix.

Imo if you can show that your software knows that 31st April is invalid, but still proceeds to input 1 May, then it can be considered "smart".

Something along this lines is perhaps showing a message "You input 31st April, do you mean 1 May? We have input 1 May for you". If I see something like that during PE I probably will not report it as a bug.

But if you simply input 1 May for the user without even notifying them (e.g. probably because your system can't even know what is invalid), in my opinion the "smart clock" is just an excuse for your software not being able to identify 31st April as an invalid date. I will still report this as a bug in PE even if you state in your documentation that it is supposed to be "smart"

@damithc If the developer mentioned this "smart" behaviour in documentation, but in my opinion it is only to cover up their inability to resolve the bug (i.e. the software did not even notify the user that the date is invalid and therefore the software is changing it), can I still report this as a bug in PE and will it be accepted by the grading team?

damithc commented 2 years ago

@damithc If the developer mentioned this "smart" behaviour in documentation, but in my opinion it is only to cover up their inability to resolve the bug (i.e. the software did not even notify the user that the date is invalid and therefore the software is changing it), can I still report this as a bug in PE and will it be accepted by the grading team?

@bingsen0806 Yes, you may report it. It is up to the team to accept it, or explain why the current behavior is appropriate, or the current behavior can be improved but that improvement is out of scope for the current version (i.e., the work already done was of higher priority than improving this behavior). The credit/penalty depends on the final response/type/severity, and can vary for each team.

domlimm commented 2 years ago

@damithc hello prof, my team and I were wondering if we could fix this 'bug' in this iteration?

damithc commented 2 years ago

@damithc hello prof, my team and I were wondering if we could fix this 'bug' in this iteration?

@domlimm hmmm... yes I suppose we can categorize this as a bug if auto-correcting dates is not the 'correct' behavior for the context in which the behavior happens. In that case fixing it can be allowed.

@Jacky142857 pls note.