Hello,
I have a date field that receives the date entered into an input, and another field that that receives the same date entered into the input stored as converted to text. I just noticed this works only half the time. It seems dates entered in the morning gets entered into the text field as the correct date, and dates entered in the afternoon get entered as the next day.
How do I fix this?
Thanks,
George
This is most likely a timezone issue. Is the info being submitted in one time zone and viewed in another?
Basically, the “Inspection date” DATE field will be displayed in the browsers local time zone, but the saved text will remain static no matter where it’s displayed.
If you want to save it on a specific timezone, you need to use the :formatted as and change the timezone to a static one.
Hi @petter,
Thanks for your response. I’m not sure that works in this case, though?
So, the records were created today, Jan 15. The work was entered as happening yesterday Jan 14, but the converted to text field says the work happened today.
What I’m looking for is, regardless of timezone, the date entered as text should be the date entered in the timezone it was entered from. Does that make sense?
Hi @gnelson,
By default, when a date/time is saved as text, it is saved in the timezone you are currently in, so this should already be saved correctly unless you specified a different timezone in the :formatted as function. From your editor, it looks like the date was entered in a different time zone than what you are viewing it from.
It’s hard to say if there’s anything wrong with your setup without seeing the app. If you’re willing to share a link to the editor, I can take a look at it. If not, you can try including the time in the Inspection Date Text to see what time difference you are looking at, and if that can give you any hints as to what is going on.
The date you see (in date field) is modified to show it according to your TZ.
If another admin go in DB in backend and is not in the same TZ, he will see it according to own timezone and not your.
If you have user worldwide, the date he select was in user timezone, but the date you see in date field in backend is shown with your timezone. You can read different post about timezone and date field from @keith
As a general rule, it’s helpful to remember that date/time in Bubble is not saved as an actual date, but as a number. This number represents the number of milliseconds since 00:00 Jan 1st 1970 UTC, which will be the same regardless of where you are. Bubble has no idea what time zone you were in when you saved it. It only knew how many milliseconds had passed since Jan 1st 1970 in the UTC time zone.
When Bubble shows that as a readable date, it’s simply showing a representation of that time converted to a readable format in the requested time zone. So if you are in Los Angeles and I am in Japan, the formatted date would look very different to us, but the number behind it would be the same: currently 1579119224027.
When you save a text, you are asking Bubble to take that number and show it as a date in a specified time zone. If you don’t ask for a specific time zone, Bubble will use your browser’s current time zone. Again, being in Japan or in LA will give you different results, even if the time is the same.
The Bubble editor will always show a date field formatted in the time zone of your browser.
Yep, as @Jici notes, a date is a date. A date describes a unique point in time. Date information should be saved as the date data type. Saving a calendar date (like “1/12/2020”) as text is pointless, unless you have a convention for what it represents. (The point being that this representation of a date is ambiguous… is it January 15th 2020? Is it December 1st 2020? If it’s Jan 15 2020, WHEN on Jan 15 2020? If you now say, “well the start of Jan 15 2020”, I now ask, “well WHERE in the world at the start of Jan 15 2020?.. or do you mean in UTC?”)
This is not to say that dates cannot be represented as text in an unambiguous fashion. For example, in Bubble, format as date as “simplified extended ISO”:
this textual representation of a date object is unambiguous
We sometimes need to do this (for example when transmitting date objects via JSON where we can only transmit text).
But all of the above probably isn’t helpful unless you understand a few other things about dates and I have a good overview here:
While all of this is fascinating stuff, I talk about date formatting at about the 13 minute mark.
Hi there, we just released two features giving you more control over handling timezones. Learn more here: New features to override timezones
