Hacker News Reader

Comment by sleepyhead | Hacker News Reader

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

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.

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

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.

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.

And now consider daylight savings time changes.

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

Reply on news.ycombinator.com