Hey guys,
In my app I want the date/time values my users select to be in the time zone of the location they have added in the input field. But I’m running into an issue.
When I try to get the locations’ offset in UTC I get the wrong value. For locations in CEST, the offset should be 120mins (2hours), but I get 60.
I have attached the image of the dynamic expression I used and the value I got. The location is Valencia, Spain.
Please let me know if the error is from my set up, thanks!
I have figured out the issue. Spain’s default timezone is UTC + 1 (which is what it showed). But during DST (between March and October), Spain moves to CEST which is UTC+2.
So the error was from me.
@chikeiroegbu I have the same issue. The offset should be correctly set automatically which does not seem the case. I am still looking into it but now you say it was your fault I would love to know how you did it.
@app11 for my case the location was Valencia, Spain. Their normal timezone is UTC+1 but during daylight saving they use CEST and become UTC+2.
So my dynamic expression was getting the location’s timezone (CEST) and the offset from UTC which is 60mins. To get the 120 minutes, I’ll need to add the offset from UTC and the DST offset as well.
Interesting. How can I add the DST?
What’s the exact setup that you are trying to achieve?
In my case I want to save a DoB using custom fields (so not using the native date/time picker. I save the entry in a custom state and from that custom state I save them in the db
Bubble things the offset is 1 hour as it does not DST.
This means that a date, for instance 1-1-2000 will result in a db entry of 31-1-1999 23:00 hours.
The options you have is because you have a location. The only thing I want is a robust way of saving DoB dates in static UTC.
I am not sure if that works and is allowed when the user did not consent with extracting that information from the user.
Also, it will not work in my case I think. So suppose you want to store a date in the db, bubble will automatically save it after subtracting the UTC offset. Bubble thinks this is 1, so one hour is subtracted.
But why? Is it a not liking the UI thing?
You can save the date directly to the database using Arbitrary date/time and then formatting your custom fields into the expression. I can’t remember off the top of my head but you should be able to specify the timezone this is saved in. If you don’t see it, go to the General app settings and check the timezone override boxes. You’ll want to save the date as UTC, so if someone enters 23rd September in New York, it’s saved as 23rd September 12:00am UTC rather than 22nd September 07:00pm.
Oh, yeah the user will get a pop-up:" [domain-name] wants to know your location", and they can choose to decline or allow it.
How are you getting getting the time from users? That help me or someone else understand how to help.
The date/time picker “sees” the time in the current user’s time zone (this one is inbuilt and doesn’t require permission from the user) and so when bubble stores the date as UTC, the DST offset is included in the calculation.
Not liking the bulky old fashion UI indeed 
Your suggestion does not let me put a static time as far as I can tell. So you can save in UTC but it will be taking into account the moment you save it. It will also use the default offset in Bubble which is wrong. So when saving in your timezone as static UTC it will use the build in Bubble hours for each time zone which is wrong in case of DST.
Offsetting in my case was not working as well. It applied first the wrong Bubble offset. So the date you save is already adjusted by Bubble in order to present it in your time zone. At least, that’s how it seems. Using the offset with a plugin, the correct offset, means that there is still one hour difference.
How I “solved” it for now is to save the DoB via backend as Current time and adjust the date,month ans year with numbers. In that case the date is nicely saved as UTC 12:00am
Yep you’re right, just checked and there isn’t a time zone selector on Arbitrary date/time.
This topic was automatically closed after 70 days. New replies are no longer allowed.
