[pg_bot]

You don't want to store two dates for an event. It's easier to store the start time of the event and a duration for the event. This will make the logic for updating your events simple. You can always calculate the end time of the event based off the start and duration.

[petalmind]

> You don't want to store two dates for an event. It's easier to store the start time of the event and a duration for the event.

Frankly speaking you could store all three (begin, end, duration) and just use whatever you need for different purposes. Just introduce a single point of entry/update that keeps alternative representations in sync.

[sleepyhead]

That would be problematic for database performance. You would have to calculate the duration on demand when querying.

[pg_bot]

In practice performance problems are a nonissue. Your API should consist of start time and duration because that is how people think about appointments and meetings. (An hour long meeting starting at noon) It's a pain to write a UI that updates two pieces of information when one piece of information changes. If you are truly worried about query performance you can denormalize the data before saving by storing start/end times as a datetime range field, but it still makes no sense to expose that in your API.

[canucker2016]

How would your code generate all the appointments for a given day?

Requirement: Must be able to handle appointments that span a day, i.e. show all Sunday appointments when there's a party appointment that starts at 8PM Saturday and ends at 2AM Sunday, or in your data model, Saturday 20:00 for six hours.

[sleepyhead]

Showing duration is helpful but so is the exact end time. Visually as a user I would like to see the exact time when the appointment ends instead of calculating it in my head. While it is not that hard to process when an appointment with a duration of 4:15 ends after starting at 2:30 but still.

As for API it makes a lot of sense to expose end time. If you for example are creating a calendar widget then it has start and end datetime for all events. With only duration available in the API output you know how to calculate the end time. More lines of codes for you.

Fetching from the API you would in most cases limit it to certain dates, for example next week. So now you suddenly do have to deal with start and end time. Not having it otherwise makes no sense.

Never had any developers ask for outputting duration in our scheduling API. It would be useful to include it but since no one have asked about it then I think having end time is more critical. https://developer.makeplans.com/#attributes-1

[sgarland]

Tbf at Google / Apple scale this may not hold true, but an addition should not cause any noticeable stress to a DB as a generated column.

Or do it in the app, of course.

[yencabulator]

And now consider daylight savings time changes.

[skeeter2020]

one of you is optimizing for transactional operations and the other reporting :)

[dgrin91]

Isn't the reverse also true? If you have start & end you can just calc duration.