I’d say it is reliable. It grabs the local timezone code from the browser using the same JS that bubble or any site would. What it is doing is a very simple calculation of a - b
The timezone values it uses for that it uses for that calculation are pulled from whatever timezone settings are on the user’s device. As long as the user’s device time is configured correctly then it will work. A lot of technologies rely on the user’s system clock (including SSL encryption, etc) and so its generally acceptable to assume user time is ok to use. The alternative of using an API or geolocation to determine an offset I would assume to be far more unreliable.
In your situation, I’d think carefully about when you are using a date range vs just multiple single dates
In bubble, a date range is simply a pair of dates [ date begin , date end ]. You can think of it as a list of dates that contains only 2 items. Bubble has some built-in features that can make working with date ranges somewhat easier in certain circumstances. In other circumstances, I’ve found it more confusing/difficult to work with date ranges.
You’ll want to play around with date / time expressions on a scratch page and read the bubble docs to make sure what will work for you committing to an app design.
You can essentially do the same with separate date fields in the db such as event date start and event date stop for each event entry in the db.
I’m waiting for someone to tell me I’m wrong for saying this, but that has seemed to bring the most clarity and work the best for me.
the follow up to this
This actually may not be correct. Don’t forget Daylight Savings. Here is a link to London’s timezone info. Besides being geographically-related, timezones are also a political designation (see:time is a construct). The U.S. the state of Indiana has different counties that each have their own timezone. I wouldn’t freak out about the intricacies of things like this this, just use the users local time on their machine and trust they know how to read a clock and know if its accurate.
What to do about all of this?
I’d consider focusing on building your application architecture first (understanding how you’ll be storing your dates in the db, etc), before focusing on the edge-case stuff like initializing dates/times with timezones–especially if your users are all expected to be in the London timezone.
This seems like very edge-case scenario for your user. A simplified UX solution might be easiest way to tackle this vs being paranoid about converting timezones.
Perhaps a conditional text next to the date picker that shows only if the user’s timezone is different than London.
The conditional:
https://cl.ly/29c68b544c6c/%255B43698dd66199f0c005ec214065fe567a%255D_Image%2525202019-08-06%252520at%25252010.07.08%252520AM.png
https://cl.ly/e986b917c4c2/Image%202019-08-06%20at%2010.18.25%20AM.png
The display text:
https://cl.ly/cd3e809f7a41/Image%202019-08-06%20at%2010.10.52%20AM.png
This involves no messing around with shifting dates and All without a plugin. 
Again, here is the an Example Application . Try playing around with the timezone in your computer settings to see the conditional in action!
The Editor