I have users from all over the world and I want to run an API workflow on my browser for all my users in their respective timezones (API workflow with date manipulation).
Date Manipulation Functions rely heavily on timezone when it comes to Daylight Saving Time.
For example: If you add a week to [March 8th 2019 5pm America/New_York], you will get a different absolute time if it’s executed in a US timezone browser or if it’s executed in Mexico timezone browser (because DST started in the US on March 10th 2019 but only started in Mexico a few weeks later).
One possible way to do that, is to create daily recurring workflows for every user from their browser the moment they sign up and every time the daily workflows run, they check for a binary flag that tells them if they need to execute an operation or not.
That seems like an inefficient solution and if the user moves to a new country after they signed up, I have no way to update the timezone of the workflow to the new timezone.
That’s a wrong assumption.
Timezones are only different ways of displaying the same time. If you add a week for different timezones, you will still get the same result as absolute time. You can say timezone don’t matter at all for date manipulation. Bubble saves dates as UTC in the database, what you see on the frontend is just one of many ways (timezones) of displayging this date.
You can’t run daily recurring workflows from the browser. This idea generally leads you nowhere.
What you probably want to do is capture the user’s current timezone when signing up - there’s multiple ways to do this you will find on this forum - and save it in your db. Then you display times on the frontend based on this timezone.
That’s incorrect for Date Manipulation Functions. Example: Right now the time in Costa Rica and in Denver is the same time (for simplicity let’s say it’s 7am in both locations). If you add 6 months to it from a browser in Costa Rica you will end up with 7am Costa Rica time in December. If you add 6 months to it from a browser in Denver you will end up with 7am Denver time in December. 7am Costa Rica time in December is not the same time as 7am Denver time in December (since there is no DST in Costa Rica) - There is an hour difference between them in December
So if I need to run date manipulation functions through API workflow - it must be in the user’s timezone for it to be correct.
I’m looking for a way to run the above example (+6 months) from Denver and get 7am Costa Rica time in December and not 7am Denver time in December.