Keying in date/time for meetings is difficult and unwieldy

[nus-se-script]

The command format requires user to key in details of a meeting's timing down to the minute. This is not only unneccessary (as many schedules may not be a strict timing), but also frustrates the user when entering a schedule since the reason for failure is not informed to the user. For example the command schedule 1 i/2021-02-29-23-23 are rejected because they do not fit the leap year timings.
However, the message is a generic

Schedule time should be in YYYY-MM-DD-HH-mm, and be valid. E.g. 2020-09-30-23-59. 
Please check to make sure the date & time exist.

This can affect users quite severely, since meetings are a core feature of the application. However the app is still useable, hence it is of severity medium.

---

_{[original: nus-cs2103-AY2324S1/pe-interim#666] [original labels: type.FeatureFlaw severity.Medium]}

[imkwokyong]

Team's Response

Since this issue mentions two bugs:

1. It's unnecessary to key in schedule time down to the minute
2. The error message is not specific enough

We choose the first bug to discuss.

We downgrade the severity of this bug to severity.Low since it only inconveniences the user occasionally, as only a subset of schedules a user wishes to key in will lack fields. Moreover, we mark this bug as response.NotInScope since:

1. This inconvenience is minor because if the user wants to enter a meeting's timing down to the hour, they could just type "-00" for "-mm". Similarly for schedule timing on a general date, the user could type "-00-00" for "-HH-mm". This is a fairly easier workaround, with only 6 characters being added as an input. Furthermore, it appears reasonably uncommon for users to not have at least an idea of when they ought to be ready for an event (e.g. if a user schedules a meeting, they likely have some idea of a hard deadline they ought to be present for it!)
2. The UG states that only YYYY-MM-DD-HH-mm is accepted.
3. Any attempts of doing otherwise will fail and return an error message.
4. The tradeoff for any such implementation is that parsing has to be reworked to be strict enough to account for invalid fields (taking into account leap years, etc.), but lenient enough to allow for missing fields & inference. While certainly not as much work as a full feature, we posit that the work put towards development of new features delivered by the dev team like note was better spent towards those features, rather than tweaking a facet of a feature that causes minor inconvenience.

Duplicate status (if any):

--