Ah, the bliss of “standard” objects :) 

This has come up a number of times over the years, here’s another post about the same issue and how to address it:

https://community.skuid.com/t/calendar-bug-startdatetime-enddatetime

Short story — you have to force an update to both StartDateTime and EndDateTime as part of the same save transaction in order for Salesforce not to mess with one or the other behind the scenes to preserve a constant DurationInMinutes. If the save request explicitly includes values for StartDateTime and EndDateTime, then the DurationInMinutes will be reevaluated server-side to reflect the new difference between end and start, whereas if only start/end are sent up in the save request, Salesforce will adjust the one that was not modified to maintain a consistent duration.

Salesforce does this in other situations as well with standard objects, e.g. OpportunityLineItem, where if you modify the Quantity but not UnitPrice, then the UnitPrice will be adjusted to maintain a consistent TotalPrice, whereas if you explicitly modify both Quantity AND UnitPrice in the same save transaction, then TotalPrice will be adjusted server-side to reflect the new Quantity*UnitPrice. 

So the “standard” SF UI (in Lex/Classic) is being “non-standard” in these situations in that it is listening for changes to one field and auto-populating a change in the other to ensure that Duration/TotalPrice gets modified behind the scenes.

As described in that other community post — best way to “force” a change to both fields is to do some Model Action / Formula logic in response to changes to either of those fields and ensure that a change is made to the other field as well. What I’ve done in the past (not the only solution) is to create a “Temp” field and then do this:

1. On Change to Start/End — dump current value of the other field (End/Start) into Temp. 


2. Update End/Start to a dummy value guaranteed to be different from the current value for End/Start — effectively forcing Skuid to consider a change to have been made.


3. Update End/Start to be Temp (which contains the original value). At this point Skuid thinks End/Start got changed, even though it didn’t really, and the save request will contain values for both Start and End.

I actually would prefer that Skuid auto updates the end date by the same amount of time that the start date changed. This is what I like about how LEX handles this. The user experience is otherwise horrible when dealing with Event times out of the box.