>>Great job thinking this through in such detail @diunuge :+1:

Thanks @vishwasbabu . I'm more involved in resource bounded environment (3D engineering). So, when I design, I like thing optimized as possible..

>>I have a different opinion here (who doesn't? :) ) and have a thing against premature optimization..... I would have preferred using time if we needed to add a new column (do we?) as it becomes obvious for somebody writing a report to manipulate the data etc)

>>Also, the API returning start time as a number doesn't seem right.

I agree with you. But it not uncommon to use int for time/date storing and data transfer. Anyway, still it's not boosting the overall application much, Using Time will not be a big thing. I can use it. 
I can convert the API format to time. No problem.
  
>>Since we already have a start_date in the calendar (of type date) I would have probably changed it to dateTime (so we could persist time in the same field)

>>The API could also return startDate as dateTime (We are breaking the existing API, but the API is still intuitive..)

I totally agree with you. Also calendar has end_date also. Best case would be using use {"(DateTime) event_start",  "(Time) event_duration"} instead of {start_date, end_date, start_time and duration}. But I didn't use it because I had to modify the existing API and the had to do lots of modifications to the MifosX for that. 
If you are ok with that I can change the API and use in this scenario. :+1: 

Thanks 
Diunuge