Hey Guys
We all know that the Current Date/Time uses the users browsers date and time. Is there a way we can capture the UTC time of the server.
Reason behind this that users device can have a wrong date time set.
3 Likes
What about working with the Geographic Location’s Time Zone ID of the current user to determine time zone (or ask them to populate a dropdown)? Then use this and the daylight savings offset to add/subtract from the server’s time as needed?
Thanks I already thought of that. But what I really want is the servers UTC time. I know I can us IPs or ask users for there timezones. But I want all my app reporting to be in UTC 0
I believe you can always output times in UTC by using “:formatas” – this changes it from a date to a text field, so you’ll want to do that after any manipulations (e.g., + 5 mins).
Thanks for the reply but what I really meant is since the Current date/time used in bubble is taken from the users browsers (personal computer) there is still not a good way of capturing an accurate Date/Time (with the exception of scheduled workflows)
If the users date or time is incorrect then the data your storing is incorrect.
1 Like
How often have you found a user’s computer to be off? (I’m curious if this is a material risk for our app too)
That’s a tough question to answer. How would you even test something like this? I know that modern browsers like chrome give a warning if they are too off.
But what is too off even mean, well I don’t know.
I always use current date/time for lots of things so I am kind of concerned too
1 Like
If your workflow does for example, update a record and set a field to Current date/time, it stores the server time in the database as UTC.
Most places in Bubble, when you display the date/time it will use your browser’s timezone, you can change the displayed timezone to UTC or any other in the “format as” function, as Scott mentioned.
Hey @mishav
Yes I am aware of that. That thing to consider here that if the users browser time and date is wrong then that conversation is wrong. What I really want is the current server date/time is exposed
I meant the format to display in UTC the timestamp written to the database, which does not rely on the users browser date/time.
The options I see available are …
A. A time value written to the database. ** the browser’s time will be shown from the cached local database, until it gets updated with the server’s value.
B. API call to the server that has the time you are interested in, example an API endpoint which returns current date/time.
C. Ask @emmanuel to provide a function for “server-current-time”.
1 Like
Nope nothing
I wanted to share that we’ve had an issue with this with one of our customers. Took hours of debugging to figure out that this was the root cause. And, our customer couldn’t even use our app because of it.
I really like the idea of being able to grab “server-current-time”. Would make it easy to put a timer on each page with 1 grab of server-current-time, and then increment it by 1 second every 1 second (client side).
When the database creates the record, this timestamp should be set to the database server’s current time.
When you look at the timestamp with the app editor database viewer, it is formatted to match the timezone of your browser, but doesn’t show the timezone in the format.
Bubble decided to omit seconds and milliseconds and timezone when displaying in the app editor database viewer.
When you have Bubble’s server send an email with a date/time, you can no longer know which timezone the receiver will be in when they read the email, so its wise to show which timezone the time is being displayed for.
Good idea, lets setup a test of this to see if there is an issue. Press the “create record” button in this test app. You should see my record in there to contrast with.
2 Likes
Its correct, because I’m in UTC +10, (the offset is how many to add to get to UTC, so its backwards as -10)…
so I’m 8 hours ahead of you. I’ll note down the lottery results …
@bubbleer do you have an issue that needs investigating?
Client’s computer time was 5-10 mins off from server time. Might not matter much for some apps, but it’s a big problem for ours. We match people for video calls and do so based on time. So, being 5-10 mins off doesn’t work at all.
1 Like
How about either of …
A. Setup a Bubble API endpoint that returns current date/time, then make an API call to it?
B. Setup a Bubble API endpoint that sets the current datetime in the database, pass it a record with Schedule API workflow ?
Option B probably has more delay. Either option would use the server’s timestamp.
1 Like
On the left is taking the created datetime and formatting it to local or UTC.
On the right is a snapshot of how the person saw the time on their browser at the time of creation.
When I created the record, for me I see the creation time as 17:44, whereas you see it as 09:44.
Your set show as the same because you are the creator.
1 Like
I will have a look I have not been keeping up with this thread.
1 Like
@mishav, very interesting idea. I didn’t quite get it the first time you mentioned it. Thanks for sharing again. We’ll have to look into this.
Our implementation would be: set an API endpoint that returns current date/time. To include timers on page, set the current date/time with this API endpoint (on page load) and then each 1 second, have it equal current value + 1 second.
In theory looks good. Risk seems to be that if it doesn’t run every second (so RAM or CPU are overloaded), then the time could get off. Any idea how often this might happen? (we’re flying a bit blind in that neither of us have ever coded with time in a client/server application so we don’t really know what’s best practice)
If you want to cover situations where users change their device’s clock to try and cheat, then the interval of “checking the real current time” depends on your business plan, if 15 minutes matters but 5 minutes over is considered inconsequential, you can defer the time check to every five minutes.
Another approach may be to send an update back to the server “user still playing” every 5 mins, and rely on the record updated timestamp.
It would be an unusual device that couldn’t track time reasonably accurately, barring intentional alteration.
You’d need to weigh the pros and cons of performance detriment of too much checking (loss of valid customers) vs risk of losses from cheating, especially if cheating only gains 5 minutes.