We are in Adelaide, Australia and our State switched to daylight savings time last week on the 6th of October at 2:00 AM local time. We will switch back to normal Australian Adelaide Time on the 4th of April next year at 3:00 am.
The problem I have is the weird (for us anyway) behaviour of the gmt() function when the date passed is 10 and a half hours before the time of the daylight savings switch. It subtracts an hour to the result.
For example, gmt("15/09/2019 17:00") returns the expected answer 15/09/2019 17:00 GMT+09:30gmt("30/09/2019 17:00") returns the expected answer 30/09/2019 17:00 GMT+09:30gmt("05/10/2019 16:29") returns the expected answer 05/10/2019 16:29 GMT+09:30gmt("07/10/2019 4:30") returns the expected answer 07/10/2019 04:30 GMT+10:30
But if the datetime passed is between Oct 5 2019 16:30 and Oct 6 2020 02:59, the result is an hour less:gmt("05/10/2019 16:30") returns 05/10/2019 15:30 GMT+09:30gmt("06/10/2019 2:20") returns 06/10/2019 01:20 GMT+09:30
Similarly, when the datetime passed is between April 4 2020 16:30 and April 5 01:59, the result is an hour more.
Is there a way to get around this gmt() function behaviour? (This also happens for the local() function the other way).
Discussion posts and replies are publicly visible
I believe this is an expected behaviour.
gmt() function needs 2 parameters, datetime and timezone. If timezone is not supplied it takes default user timezone.
In your case timezone is Adelaide.
Now consider this- the date time supplied is considered to be gmt and then adjusted to user timezone. Therefore 5th Oct 16:30 GMT implies daylight saving time has already started in Australia.
I can see the same behaviour for my city Melbourne. +10:00 :)
Trust this answers your question.
Hi TJ, one example of where we use the gmt() function is in our Appian Web API that calls a Process Model. The API has a couple of datetime parameters, startDateTime and finishDateTime.
The external application will pass a JSON string to the API in the body as something like:{"employeeNumber": "2703618","startDateTime": "05/10/2019 14:00", "finishDateTime": "05/10/2019 18:00", "lengthOfMealBreak": 0 }Start date is 2pm and Finish date at 6pm local time on Oct 5, for a total of four hours worked.
But the Appian Process assumes that these dates are UTC so in the process model, the values at the start of the process are automatically converted by Appian into local time equivalent. One of the first nodes I have in the process is to convert the dates via an expression so something like gmt(ri!startDateTime) and gmt(ri!endDateTime). The startDateTime would be correct but the finishDateTime is off by an hour.
One of the ugly work-arounds we can think of for the above scenario is to force the external parties to pass a UTC datetime, though this is Web API specific.The other thing I'm thinking that will apply to other parts of our application is to create a reusable expression that calls the gmt() function but then adds or subtracts an hour offset if the datetimes fall within the affected ranges.
Hi, besides any other issues with timezones, timestamps transported via any interface from/to an external system must be UTC. Then there is a clear state you can work on. This is what I try to enforce in all our projects.