Problem with sending <time> from date and time picker to bubble


I have been trying to send the date and time from the ios date and time picker. The date picker is set to “date and time”.
From the date and time picker --> when value is changed, - so far I am able to only get the date right but not the time.
I have a page variable “picked_date” of type “string”.
When the value is changed in the date and time --> next step is --> format date to string
set value of "picked date " to the action data format date to string.
And from the API the bubble date parameter is set to the picked date.
I have tried it multiple times but I am not able to get the time.
I am doing something wrong if anyone could help me out with it.

** when I format the date to string i have tried all of this below.

  1. dd MMM yyyy ‘at’ HH:mm
  2. MMM d, yyyy h:mm a

#2, Thanks for posting here. Dates are always a tricky portion to take on in development. May I ask what might happen if you grabbed the timestamp string from the date object and passed that instead, if you could use that on your bubble side. Those timestamps are great to use when possible because when you need to use it in Dropsource later, Date Objects can be created based on those timestamps for formatting.


hi @wade Thank you for reaching out. I tried doing what you had suggested but in the network activity it gives an error saying that, its looking for a date and got a string instead.
However I went on to further try the same method that I was trying earlier.

I noticed that the date and time is being display correctly in dropsource app and there is a ‘T’ between the date and time. However the same data in bubble has the time wrong. I tried to display the same date and time in the bubble app and it is different compared to the dropsource app.

The above pic is the date in bubble.

The same date is displayed in dropsource as.

I have noticed that the hour number is always wrong in bubble. I think it is because of the T in between.

I have also tried this but doesnt work where there is a time format section.

#4, 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.


@seanhoots thank you. You’re a blessing to this forum.


I ran a test here. I have a datepicker and a label that displays the datepicker’s timestamp string when the datepicker’s value is changed (That’s an event for the datepicker element). I ran the app and changed the date in the datepicker and then took the timestamp string I see in the label text and typed it into the website

The timestamp gives the Seconds Since Epoch in UTC format. I have a screenshot here showing the datepicker’s value I changed it to, the seconds given in the timestamp string and I typed them into the helper website and you can see that it returned the date and time for that value in UTC. I confirmed with a 2nd site to double check it. That came out the same.

A solution here would be to submit to dates to bubble in the seconds since epoch string (date picker -> date -> timestamp) property. Bubble has the ability to handle this unix timestamp in seconds string for your needs. Then when you pass a date back to Dropsource, if you pass it back in the same seconds since epoch string format, you could use it like that, OR we have an action called Create a Date from Timestamp that allows you to create a date object using that timestamp as well.


Hey Wade thanks for the confirmation.

Does dropsource provide any support for timezones (without using some external api timezone converters) ?
Because obviously for most practical purposes you’re not always going to display times in UTC but in some other timezone.


Good question… I ran another test using the Date Object as the way to convert for local app usage. I think that’s probably how this strategy will work effectively. So if you take a timestamp string (which is a UTC seconds from epoch string) and you use it as the parameter for the Create Date from Timestamp action (where it asks for date use the timestamp -> double value). The date object will convert to its current timezone for the device.

I took a test timestamp string of 1543474379 which is the UTC equivalent of 11/29/2018 @ 6:52am (UTC). I created a Date from Timestamp using the test timestamp string as its parameter and then set a date picker’s date to this newly created date. The Picker showed the date and my local time (CST currently which is 6 hours behind UTC). This means the date object was successful in converting to local time when using a UTC timestamp string as the parameter when creating the Date object.


@seanhoots @wade You guys are awesome!