Bubble changes dates when storing them

[maxiogas]

Hello everyone, sorry for the hour , I’m going to leave this question here in case someone can help me.

Something very strange is happening to me.

In my workflow, I was having a problem. When creating a new record in my database, I was trying to save a date.

What happens is that in the workflow I can see that everything is running fine and the date matches what I want to save.

But, then in the database, the record does not match.

You can see in the images that the workflow indicates the following dates:
Deal of the day: Jul 1, 2021 1:00 am
Text: Jul 1, 2021 1:00.

Basically I am storing the same value only in two different properties, the first is stored in date format and the second in text format.

In the other image you can see how the record does not match the workflow.

“Deal of the day” matches, but in the “text” property the record does not match what the workflow indicates, it saves a different date and time.

I can’t find out why this happens.

Technically, if I am using the same source for the date and in one it is stored correctly, in the other it should be stored the same.

In the workflow you can see that the date is not altered, a new record is simply created without any change.

Even if I try to save the current system date the same error occurs.
In one property it is stored correctly and in the other it changes the time.

Anyone have any ideas or something similar happened?

[BrianHenderson]

Are you familiar with the concept of UTC or “Zulu” time? I wonder if you’re encountering something related to time zones.

[rpetribu]

Hi

What is the action you are using to save this in your database? Could you share it?

[maxiogas]

Is just crearte a thing. Just a simple action

[maxiogas]

I thought the same thing. but if I am saving exactly the same date in the two properties the same dates should be saved, there is my doubt.

[BrianHenderson]

Well, it seems you’re dealing with two data types: A date, and a text. In Bubble, by default a date/time value will always show in your time zone. However, a text value is static. I still suspect you’re running into something like this but you haven’t provided screenshots of exactly what you’re doing so it’s all speculation.

[rpetribu]

Yeah…
The problem should be in the “create a thing” action…

[boston85719]

This is associated with what @BrianHenderson mentioned. The date value you see in the database is shown in your current timezone. Chances are you are running the function to create the entries and the date value has a different timezone applied than your current timezone. Also, if you are seeing this when a user in another timezone creates the entry, that is why too.

You need to save the dates in such a way that they are stored using the timezone they are meant to be for.

[sudsy]

@maxiogas

You can see in the images that the workflow indicates the following dates:
Deal of the day: Jul 1, 2021 1:00 am
Text: Jul 1, 2021 1:00.
[…]
if I am using the same source for the date and in one it is stored correctly, in the other it should be stored the same.

In fact, they both represent exactly the same instant (moment) in time. It’s just that the text version is in UTC, and the date version is displayed in your browser’s time zone; so both @BrianHenderson and @boston85719 were on the right track.

Why was the text version saved in UTC? Simple. You didn’t tell it otherwise. UTC is the default if a time zone is not explicitly set.

Therefore, you can get the behavior you want by specifying the date format and choosing the desired time zone…

And if you use the “Z” format specifier, it’ll output the timezone so you can see for yourself.

HOWEVER

Having said all that, the burning question is, why is a date being saved as text to begin with? Generally speaking, it’s bad practice. There are [rare] instances where it might make sense, but it’s usually a bad idea. Date/time values should be preserved as such, as they take up less space, are more performant, and more flexible. All date/time info is preserved if it’s stored as a date data type. That’s lost when it’s converted to a string of characters.

-Steve

[boston85719]

@sudsy

Why was the text version saved in UTC? Simple. You didn’t tell it otherwise. UTC is the default if a time zone is not explicitly set.

I’m a bit confused. Wouldn’t the default timezone be the users current timezone unless otherwise explicitly set?

When saving the text field as the dynamic expression for current date/time, the timezone selection is the user’s current timezone, so the text value should be that, and only UTC if the user was in UTC timezone.

[sudsy]

@boston85719

Wouldn’t the default timezone be the users current timezone unless otherwise explicitly set?

Nope. It’s quite simple to test. See for yourself.

@boston85719

When saving the text field as the dynamic expression for current date/time, the timezone selection is the user’s current timezone

But there is no “timezone selection” until / unless it’s explicitly set. Remember, this is happening server-side when creating a thing - not in the browser - and the Bubble Manual states, “In situations where a web browser is not involved […] we use UTC time in our calculations.”

-Steve

[boston85719]

Never knew that. Would have assumed the text would be saved as the users default timezone.

I’ve done some tests and now understand the differences.

If you use formatting options, the default timezone is the users current timezone and it is applied to the value saved in the database

However, if you don’t use the format operator the default timezone is UTC and the text value will be saved in UTC, while the date will be in the Users Timezone.

[sudsy]

@boston85719

while the date will be in the Users Timezone.

A date data type isn’t actually IN any time zone. Time zones are relevant only for display and manipulation for/by humans - not for storage (unless the date is stored as text, in which case having an associated time zone allows the precise moment in time to be reconstructed into a proper date type).

Behind the scenes, dates in Bubble (as with most modern computer systems) are nothing more than integers - really big integers, but integers nonetheless.

Basically, time zones are an artificial construct invented by humans so that a given time in a particular time zone represents roughly the same time of day around the world.

-Steve