Is It Possible To Capture The Current User’s Browser Timezone ID?
I’m trying to figure out more date/timezone issues, and need the originating browser timezone (current users timezone) to be passed through the API so that it can be reformatted in moment.js or by some other means.
I.e. 5pm in Germany where the user submitted the date must convert to 5pm in New York time so that at 5PM in new york, an API workflow runs.
Try Keith’s free Browser TimeZone and Locale plugin. Should do the trick!
@JustinC I am working on the time issue right now. I am planning on putting together a tips post tomorrow on what I am doing that has helped me wrap my head around time issues. I am looking for a plugin that captures the browsers time zones UTC offset.
I am currently using the plugin @petter suggested and it does get the browser timezone ID.
Do you happen to know of a way to get the browsers timezone UTC offset? Or perhaps a way, after obtaining the timezone ID to get the UTC offset value?
I haven’t tested it myself, but I think the Date & TimeZone Tools can give you the offset.
What I’m after is a string date being translated into a javascript date, at a specific timezone.
With all of the back and forth and the 10’s of posts on time zones I don’t understand why Bubble hasn’t gotten a grasp of this and implemented moment.js in a way that will allow a date to be formatted into a specific date in a specific timezone.
Keith’s Calendar Grid Pro is able to do that, or you can use some Javascript using the Expression plugin:
//specify the time zone we cant to convert into
var target_zone = '**INSERT TIME ZONE ID HERE**';
//specify the timestamp we want converted
var date_string = '**INSERT THE DATETIME TO BE CONVERTED, FORMATTED AS TEXT HERE'**;
//convert time timestamp, and return it in JavaScript date
moment.tz(date_string, target_zone).toDate();
Use this formatting when you set up the custom formatted as:
yyyy-mm-dd HH:MM:ss.L
I share you frustration that working with timezones in Bubble is a horror show. It’s all about prioritization though; I’m sure they will implement it some day, but there’s a long queue of other features that also have countless threads begging for their release.
In general, the Calendar Grid Pro plugin has saved me an immeasurable amount of hours working with this stuff, I really recommend checking it out even if it’s on the expensive side. With all the work put into it, the price is well justified.
Won’t we still need to capture/know the original browser timezone though?
What I’m after is 0900 on December 11th submitted from Chicago to be formatted for 0900 on December 11th in Lisbon PT (for example).
Not necessarily, as this script will do exactly what you described (convert a time formatted as text to that exact time in any given timezone, meaning 09:00 will be 09:00 in New York, Los Angeles or whichever time zone you prefer.
Where you would need to know the browser timezone though, is if you want to combine it with a date/time picker (which may be exactly what you want do to…). In that case, you’re back to square one. So what I did is that I replaced timepickers with dropdowns with numerical values instead (one for hours, one for minutes, and for year/month/day if needed.
I know it’s somewhat limited, but it’s the best solution I’ve found so far for doing what you describe.
Thanks @petter I had checked out that plugin previously and it doesn’t work. I emailed the creator of the plugin without response as of yet, but I am holding out little hope to get details back on it.
I’ve tried to use the bubble pre-installed current geographic location tools to get the UTC but it doesn’t work and I needed to submit a bug report because of it.
Hoping that something like the bubble pre-installed tools will do the trick if the bug could be resolved.
I did the same thing but only for the times of days. I needed to have a bit more control over the look of the date/time pickers available so the best way was to create a database datatype for time slots and use those in a drop down.
What I have done after that is to combine the data with that of the date picker to get the date with the “picked” time slots to get an entry still recognized as a date…other formatting options were changing a date into a text.
So with this I get the ability to set up dates in other time zones so long as I have the UTC offset value, which I am hoping to get from the browser, but for now I am using a database datatype to convert the date saved from the above screen shot into the users current timezone using something like below
The problem with this is that I have to have the database datatype
Any before I go creating a bunch of conditionals to account for Daylight Savings Time, I’m hoping to come across a way to capture that UTC offset value to use, as I feel it would already incorporate Daylight Savings Time in it, saving me a lot of time trying to set up dates / times.
@JustinC What I just explained may be something that could help you since it sets everything to a UTC timezone, but later you convert into the timezone of the user if you have their UTC offset value. Do you have a way to get the UTC offset value from the browser?
Also, @JustinC do make the same date and time for every time zone and disregard the users time zone as it compares to the “creators” timezone, so if created in Chicago and the person viewing the page is in Lisbon and those dates and times need to be viewed as the same, the easiest way is to just convert it to text and display it as text.
If however, you are in need of using it as a date still for search purposes etc. then again, my points made previously would help.
I can’t say the exact cause in your case, but generally I’ve found the :current geographic position to be unreliable, as it can be affected by all sorts of settings in your browser, operating system, device, Google API, ad blockers, etc. I may be wrong, but I suspect Bubble can’t do anything about your report as it’s outside of their control. Not saying that you shouldn’t have filed it, but that it’ll probably make sense to look for solutions elsewhere and not wait for Bubble to get back to you.
Anyway; using the SET HOURS to can lead to unexpected results, based on where the user is, regardless of the date you are using is already saved in the DB. Remember, Bubble doesn’t save any time zone, it saves time as milliseconds since Jan 1st 1970, so if you’re setting the hours to say 17:00, that will give different results if the user is in LA than in Tokyo, because it will be set to five in Tokyo time or LA Time.
If your date is set to 00:00 in the correct time zone you want it saved in, then adding hours rather than setting them will give you the right time. Adding 17 hours to 00:00 will give you 17:00 regardless of the user time zone, as long as the original date is in the correct zone.
Is this reply to the set up I have below:
This set up is using the time slots I have created in the database
Which is saving the data in the database as so
This is not saving the date in connection to any time zone other than UTC, regardless of where the user is who created the entry.
I created the entry in Bangkok Thailand, but the date is manipulated in the above screen shot using the text element set up below
Which has taken this data of the offset UTC from my database
At this stage of my setup and testing I am under the impression that it doesn’t matter where in the world the user who creates the date entry is when they create it, as long as I am able to convert it to the user who views it timezone, they will see it as the correct time in their zone.
My use of this is for a ticketing system for events. I feel that if a user is viewing the event hosted in Las Vegas from a computer in Bangkok they should see the date/time the event starts in accordance with their timezone and if they create the event in New York the set up won’t need to take that into account ( i.e. event in Vegas begins on December 31 at midnight will be seen in Bangkok as beginning on Jan 01 at 3PM when a user in New York enters the date as December 31 at midnight - and once entered the person in New York who created it will see it as Jan 01 at 2AM ).
If I were to do as you mention:
I wouldn’t be able to allow an event creator to set the time the event starts, but I think what I set up eliminates the possibility of unexpected results except at this point in the case of daylight savings time.
The one thing I need to do to make it work properly though is to have a data field to set the timezone of the location of the event, so that when an event is saved, it is known which timezone to use as the “base time” saved in the D.B. This way, a user in Bangkok who creates the event to start on Jan 01 at 1AM will see it as starting at Jan 01 at 1AM instead of how it functions now…essentially the “base time zone” now is UTC and I need to have the ability to set it to the event creators time zone so all other time conversions I do show correct date and time in their time zone.
This I think is similar to what you mentioned:
I am still in the testing / building phase but the idea of getting the UTC offset from the browser is where I am stuck, but as my app is to be used solely in the USA I at this point might just add the data to the database for the 6 timezones in the USA. If what I do saves me a bunch of headaches with time I am planning to post a tip on the forum. I’ll update this thread with a link to it if I get that far.
Yes, you’re right about this, so you may not need to take my reply into consideration. I wrote it mostly because I saw the structure in your screenshot, and thought I’d mention that this can cause problems – though not necessarily with your current setup.
So yeah, sorry about the confusion, but converting the date as the user “sees it” in his browser will indeed work even with the Set hours function.
This topic was automatically closed after 70 days. New replies are no longer allowed.
