@hg.hermes.l, the T and Z you see in your dates are perfectly fine. It means the date is being represented in the ISO_8601 format.
The reason why you’re seeing different times in bubble and dropsource is due to timezones.
Dealing with timezones in development is a huge topic so will just briefly explain what is happening.
Here is a question for you.
If I tell you to meet me online at 4:00pm i’m sure you first response will be, 4:00pm in what timezone.
Because simply saying 4pm without any context is very ambiguous.
If we’re in the same location or in the same timezone, then 4pm will implicitly mean 4pm in our timezone.
This is why most of the time when stating times online you attach the timezone, e.g. 4pm EST (Eastern TimeZone)
In computer systems, to avoid such ambiguities you always have to specify the timezone of dates when you’re storing them. This will help you do display it appropriately without any ambiguity.
A convention is to store the time in UTC /Zulu (GMT timezone). The Z you see at the end of the time means Zulu timezone.
Bubble stores all times in UTC (i.e GMT ± 0 offset).
But when displaying dates, bubble display them in the timezone of the browser unless you explicitly specify the timezone it should display in.
So when you view you data in bubble database it is showing you the time in your browsers timezone, is likely going to be different from UTC unless you leave in a GMT timezone like UK or Ghana.
When you request for a date from bubble through an api, it will always return the UTC time.
This is the reason why you’re seeing the times as different in the bubble database display and in dropsource.
From the images you showed i’m guessing you’re living in an EST timezone (GMT -5). That is why the date you see in bubble browser (5:36pm) is 5 hours less than the time in UTC (10:36pm) you see in dropsource.
So the obvious question is how does Dropsource handle times?
If a user pick a date/time and convert to a date object and send to bubble, what timezone is it using?
I haven’t done a lot of testing here so @sue and @wade could confirm things here.
But from my little observation, when you bind a date variable in dropsource to an api parameter which is a date type (formated as string) like the way bubble is, dropsource sends the unix timestamp.
Unix timestamp is actually timezone independent because by definition it is the number of milliseconds (or seconds) that has passed since midnight of Jan 1 1970 UTC. So when you give a unix timestamp there is no ambiguity what it means.
Luckily bubble knows how to handle unix timestamps (i wont be surprised if even internally bubble stores dates as timestamps in the database).
If you were to send a date as string (e.g. “27/11/2018 14:40:00”) to a backend you may have to specify the timezone or convert to UTC format.
There is more to talk about on timezone but i hope at least this gives you some ideas on why you’re seeing the different times.