Tech Spec - Event Length

[gflacruz]

Summary:

Provide a short (1-2 sentences) overview of the project, including its purpose and goals.

Replacing the end time entry input to just ask the user for a duration instead. The goal is to prevent the user from submitting incorrect end dates and hopefully be a more intuitive process.

Scope:

Define the scope of the project, including what it will and will not include. List the features, functions, and requirements of the project.

• Two drop downs added (hours and minutes) to the single event creation form
• Function that grabs duration and calculates an end time for the form
• Validation so that users can't input 0 duration or a duration longer than the max

Data model:

No changes to data models should be necessary since we should be able to calculate and submit a new end date with the user's duration input.

User Stories:

User will now enter a duration when creating an event.
User selects between between two drop downs one for hours (thinking 0-6) and one for minutes (thinking 15 minute intervals)

Implementation Details:

Provide details around how the feature will be implemented, and justify any decisions made. For example, this may include stuff that looks like:

Two drop downs will need to be created for hours and minutes. We will then need to grab the initial start date, convert the duration to milliseconds, calculate the new end date that will passed along, and finally do a validation check for any edge cases.

APIs:

N/A

Security/Privacy:

N/A

Testing:

Possibility of a test or validation needing to be added to ensure user doesn't input 0 hours and 0 minutes as a duration but I believe the current validation will prevent this due to the end date not being after the start date, which should throw an error. Current tests will need to be updated since we will now be allowing users to have a different start date and end date for single events to cover the edge case of an event taking place in times when the day changes. (for example 11:00pm to 12:30am next day)

Open Questions:

What is the maximum duration that we think any one event should be?
Do we like the idea of limiting the users inputs with two drop downs (hours and minutes?)
Should we only allow users to have 15 minutes intervals for the duration or allow any minutes (0-59 or x:00, x:15, x:30, x:45?)

Deployment:

N/A

[timmyichen]

Thanks for writing the first official tech spec! :) These are my comments:

Two drop downs added (hours and minutes) to the single event creation form

What are your thoughts on a single drop down, where we allow them to set the duration to be 15/30/45/60/90/120 minutes? I think two drop downs for minutes/seconds might be a bit cumbersome for the user to use.

No changes to data models should be necessary since we should be able to calculate and submit a new end date with the user's duration input.

Will this solve issues we are currently having where timezomes occasionally mess up when the start and end are on different days? The way I see it, there are two options here:

• Store start + end date based on the user providing the duration
• Store start date + duration, derive end date from duration when returning data to the user

I'm not sure which way is better - but I think it might be worth investigating?

[Caleb-Cohen]

What are your thoughts on a single drop down, where we allow them to set the duration to be 15/30/45/60/90/120 minutes? I think two drop downs for minutes/seconds might be a bit cumbersome for the user to use.

I agree with this, but open to other ideas if there are any.

Store start date + duration, derive end date from duration when returning data to the user

how would we derive end date with the proposed inputs?

[timmyichen]

how would we derive end date with the proposed inputs?

End date = start date + duration? 🙃

[Caleb-Cohen]

how would we derive end date with the proposed inputs?

End date = start date + duration? 🙃

I believe what's been proposed is event duration with regard to the time. In other words, how many minutes will an event last once it's started, not how many days/months will it reoccur.

[timmyichen]

Whoops - I meant end time :P

[gflacruz]

What are your thoughts on a single drop down, where we allow them to set the duration to be 15/30/45/60/90/120 minutes? I think two drop downs for minutes/seconds might be a bit cumbersome for the user to use.

I like the idea of just a single drop down that is gonna cover 95% of cases.

Will this solve issues we are currently having where timezomes occasionally mess up when the start and end are on different days? The way I see it, there are two options here:

* Store start + end date based on the user providing the duration

* Store start date + duration, derive end date from duration when returning data to the user

I'm not aware of the issue of timezones messing up. If you are talking about the current validation that prevents users from having a different start date and end date. that validation shouldn't be necessary anymore.

As for the implementation of calculating the end time/date, I saw that date-fns has an add function. I think this should easily let us grab the duration and calculate a new end date.

[Caleb-Cohen]

@gflacruz Thanks for being the first to give this a try!

@romanstetsyk Can you chime in on this tech spec related to the back-end tests? Our current idea is to take the start time + length, calculate an end time, and pass that end time to the event object to utilize for testing. Do you like that idea?

[romanstetsyk]

@Caleb-Cohen Yeah, we can do that. As @timmyichen said, the options are

• Store start + end date based on the user providing the duration
  This is how it currently works. You don't need to change the mongoose model, only the schema that validates the form body and a function that creates an event object. Calculations are made on the back end.
• Store start date + duration, derive end date from duration when returning data to the user
  Need also to change the mongoose model. Calculation of the end date is made on the front end.

Which one is better? I'm not sure. But the first one I think would be easier to implement