This method helped me:
Continuing this conversation because I really want this to work:
You can use my notifications script to do this without using a 3rd party and append the necessary info to allow it to be added to google calendars.
Sorry, my post may have been misleading. By zulu, I meant the ISO format. Back in the day, Glide really struggled with different date formats, so I believe they introduced the underlying ISO format to be more globally recognized and properly convert to the user’s region format. With the exception of the log sheets, which I believe are possibly zulu/gmt (probably server) time, all dates and times are stored as local time to the user since that is being calculated on the user’s device.
The only solution I can think of is to get the user’s local time zone and do the math to store it as a true zulu/gmt time.
Ya, that’s what I was afraid of…Glide has made huge strides in figuring out date/time issues across timezones etc, but scenarios like this (automations/webhooks that use the timezones) still occur.
I also noticed issues when sorting by timestamp. If somebody half the World away is writing to the same log as I am, sorting is off.
Indeed.
Epale @Robert_Petitto
I am sure you already thought about this but here it goes.
Thanks for thinking of a solution! The issue I’m facing is that the 5 you’re referring to is different for everyone using the app based on where they’re at in the world.
Isn’t the solution just to collect the users timezone offset when they sign up, and store that in their user profile?
Ultimately yes. The tricky thing is daylight savings time. Probably doable with an if then else column. Thinking maybe a drop down on the user profile sheet. If then else to check what the date is determined if it’s a -5 or -4 for example. And then only allow the add to calendar button if that information is filled out in the profile.
I’m also using only glide tables, so importing the list of available time zones is not going to be fun.
I know! Glide needs a current timezone column! @Mark
mmm, Glide Tables are great, but the problem is you continually run into dead ends when it comes to integrating with external services.
I wouldn’t mind betting that there would be an API out there somewhere that would return a current GMT offset given a set of co-ordinates. But even if there is, it won’t help you as there would be no way to get that data back into your Glide Table
Exactly. Oh well.
Still want an upgrade over this workaround, but you can copy them all into a Sheet, have a “Moved?” boolean column.
Then show them as an inline list in the app, filter by Moved is not true, have a custom action to add row to the Glide Table and set the Moved column to true. I have been doing this recently.
Does this still work if I didnt start with a Google Sheet? The app is built completey with a Glide table.
Oh that’s a no go then. Due to cases like this I always start with a Google Sheet to have a fallback option.
This solution doesn’t work for you?
It will, but Bob’s challenge is that his users will be in different time zones. So he really needs to have the GMT offset as a user attribute. And it’s further complicated by the fact that the offsets can change at certain times of the year due to daylight savings adjustments. And it’s even further complicated by the fact that he’s using Glide Tables only, which pretty much rules out any automated option for keeping the values updated.
Seems like a problem only Glide can solve @mark