Hey everyone, I know this question has similarly come up multiple times already over the years, but I couldn’t find a definitive answer anywhere yet. I’m running into the following issue:
I’m using the Email Trigger workflow (same issue in other workflows btw)
One of the columns is a datetime column. Let’s say that value in a certain workflow run is 07-11-2025, 11:00
Everywhere in the app, this looks good.
However, here comes the issue:
When pushing this date to Google Calendar, the event start datetime becomes 07-11-2025, 12:00
I have managed to find a workaround in another workflow (using Zapier), but it’s not ideal and I want to have a robust way to make sure this works properly.
!! For as far as I remember: every time I select the date myself from a date-time input, there is no issue. For that reason, I think it’s probably due to the workflow running server-side, but that still doesn’t tell me how to fix this.
I’m in Europe/Amsterdam timezone, currently GMT+1.
I think Glide stores date and time as if they were UTC +0 time regardless if they really are or not. I think they they always put the zulu code at the end. You may have to use a template column or math column to offset your date to account for that. I’d probably use a math column. You can use Format Date to get your offset, then divide that by 24 and add/subtract that value from your date column. Basically trick Google into using the correct time.
Disclaimers: I don’t remember if this was ever fixed, and I’m not certain on the impacted columns.
As recently as December 2024, one of the date column types (format date, I think, but maybe it was the API v1) saved the time value in the user’s local time and appended the Z/zulu to the end of it making all sorts of issues.
@Jeff_Hager@NFNHello Both of you, thanks a lot for your replies and effort to help. Due to other priorities, wasn’t able to get back to this and neither did I want to .
However, out of respect for your effort to help me, I dedicated the last hour to try again using your suggestions. Nonetheless, it didn’t work and this remains a major headache every time again. When using a user-selected date (client-side), no problem. But once a workflow is processing any date-time value server-side, it becomes a total nightmare.
In conclusion: I’ve created a workaround using Zapier, because there I can control what is sent to GCAL exactly. Thanks again for your help!
PS. because here in the Europe/Amsterdam timezone we have varying offsets (+1 for winter, +2 for summer, I can’t hardcode a reliable fix using a math column)
The format date column to calculate the offset should account for the winter/summer changes throughout the year. I believe it gets that offset directly from the device.
Good point, especially with the format date column. It would determine the offset from the server instead of the user device, which I assume the server is always GMT +0. You would probably have to do something where you calculate the offset datetime and store it in a basic column before running the server side workflow. I’m sure there is a little more to it based on your scenario, but that may be the root of your issue at the moment.
@Jeff_Hager you’re right. That’s the issue. Since it’s running server-side, the offset column returns 0. I would need to add a bunch of columns or other logic to make this work reliably, so for now I’m sticking with the Zapier solution. Nonetheless, thanks a lot for your help!