Overzealous validation of birthdays

[jedkohjk]

Changes in system time can reasonably happen when changing OS (not updated), when changing timezones, or by setting directly.

We may resonably want to set a birthday to a future date, in a timezone that is ahead of us.

However, this is not allowed by the app.

[nus-se-bot]

Team's Response

Due to a lack of reproducing steps, I'm unable to identify what conditions should be satisfied to produce the bug. For example, was the timezone change done when the application was open or closed?

Items for the Tester to Verify

:question: Issue response

Team chose [response.IssueUnclear]

• [x] I disagree

Reason for disagreement: I reported a feature flaw, not a functionality bug. Hence, I was commenting that blocking future dates is not ideal, not that there are specific steps that, if followed, cause an error.

Hence, I stated that changes in system time can happen. This is regardless of when those changes in system time occur (whether the application is open or closed).

The issue is a feature flaw because it is reasonable that we want to store future dates (based on our system time) as birthdays.

Here are 2 possible scenarios where it may not be ideal:

• This is an example I suggested in my original report too (albeit less elaborated on). Say for example that someone migrated to the US. Their time is 12hrs behind that of Singapore. Their friend in Singapore just conceived a baby and they want to record the baby's birthday. In Singapore time, the baby was born on 22/11/2023, but the date in the US is still 21/11/2023 because of timezone differences. Their system time follows the US timezone. Hence, the app blocks them from recording the baby's birthday as 22/11/2023.

• I have set up dual boot (linux and windows) on my laptop. When switching between systems, the time is not automatically updated (I think the system clock for windows does not tick when I am on ubuntu). So my system time often lags behind the actual time. What is perceived as a future date based on the system time, may actually be a past date. Hence, it is annoying that dates are validated based on system time because the system time may be wrong.

Allowing future dates serves to make the app more flexible and account for the above scenarios. I do not see how allowing future dates would can hinder the operations of the software. I believe this fits the course website's description of overzealous input validation:

I believe my explanation of the issue was sufficiently clear in the original report. I do not think the dev team's requirement of reproducing steps is justified for a feature flaw like the one I raised.

---