I’m trying to get the bottom of date saving issue. I’m having trouble understanding what I am seeing in the Data Viewer.
I assume that 8base saves dates in UTC. And that it expects dates supplied to it to be converted to UTC in the first place.
However, I think the data viewer does not display dates in UTC. I wish it did, because it should be a reflection of what is stored in the DB. However I believe it localises the UTC date to be in the user’s timezone. What I can’t ascertain, is how it determines what the user’s timezone is?
There is a localization setting for our workspace. Currently set to America/New York UTC-5:00. I am physically located in a different timezone, in the UK. When I look at dates in the data viewer what is it showing me?
Hi, Daniel.
You are correct that 8base stores date fields in UTC. Data viewer shows and stores date with shifting with timezone where you are physically located.
For example:
You try to save time time1 and your timezone is UTC + 03. That means 8base will store time1 - 03 hours (UTC). When you try to get next time this data from 8base it will show the date based on your timezone where you are located.
Currently, changing timezone in settings doesn’t affect date representation in data viewer.
We generally don’t need to update any dates using the data viewer, only to view them. In our case, dates get written to 8base using GQL mutations where the date is passed as a string in ISO format (yyyy-mm-dd). We assume that these are interpreted as UTC as no timezone is explicitly supplied. Another assumption (hopefully correct) is that 8base doesn’t try to guess the timezone based on the origin of the http request underlying the GQL.
So our only issue is understanding what timezone the dates are being displayed in when we look at them in the viewer. To avoid confusion I would suggest a new feature request: Allow users to specify the timezone for displaying dates in the viewer. Something like what you find in AWS Cloudwatch. It’s not obvious that dates are displayed in the local timezone and I would guess it’s not what most people would expect. The more logical thing would be to display it in the timezone it is stored in the DB and make this information visible somewhere in the viewer.
I agree with you. I run into the same confusion myself. - I’m tagging @estebanf to add this to our usability backlog - of course we have a lot going on and I don’t know of a timeframe, but hopefully we can get to it in the coming months.