Without watching the video and giving a quick reply - The time zone shown is dependant on the users language settings on their OS if that’s what you mean. For example, I had to change my Windows language to English (Australian) to see the correct format.
I believe Adalo takes care of it automatically based on your OS settings.
I’m pretty sure Adalo stores date/time as an absolute value of time at UTC/GMT that is then interpreted by the layers on top. As @Briggsy says that means it’s dependent on your OS having the right localisation settings.
BUT also Chrome (and I believe ONLY Chrome) also has its own localisation setting and also needs to be set to your locale.
Thank you, I know this should be the case. But I’ve checked and the users in the US are getting their records recorded in Europe (GMT+1) in the database.
So basically, it’s not getting the right time from the users device.
I thought it could be a one off case, but two different users on two different apps have reported this issue to me and they are both in the US.
I’m wondering if I should just subtract -6h every time it stores data so that it’s accurate for now.
Have you tried it on a new app? Is it recording the data correctly for you?
I think it’s correct behaviour for the system to record the date/time in UTC and then the UI to handle the localisation. It’s fairly common that when you set up a profile on a platform to have to set the timezone you are in.
Of course that’s maybe what your customers aren’t expecting to do. But if it was me I’d set the application to have a timezone variable that even if it’s not shown to or set by the user rather than change the actual value in the record itself. That way if down the line I was going to make the app for other timezones it’s the app that changes, not the data.