UNIX Timestamp/Date Bug in Bubble

[hassan3]

Since the last 24 hours, all UNIX timestamps from API, are getting stored in DB as 1970.

This is a bug on Bubble side.

My app has stayed unchanged for the last 6 months and everything worked fine. And since yesterday, all dates are getting stored as 1970.

Confirming that API response is unchanged.

Simple Workflow -

API Call → Get Timestamp (UNIX) → Create New Thing in DB

Issue is date is getting saved as 1970.

In my API call I’ve marked the timestamp as ‘UNIX’ already - and it has been working fine for the last 6 months. No changes were made to the app (no updates), and since yesterday its saving as 1970.

Confirming that others are facing the same bug.

Contacted Bubble support but haven’t gotten a response.

[hassan3]

Another user is facing the same issue -

Timestamp convertion to Date(UNIX)

Hey! Thanks for this tip. It’s unfortunate that the field type “date (UNIX)” is not documented by bubble. I was using it until now to convert timestamps (in seconds) that I get from the chargebee API into bubble dates and suddenly it stopped working yesterday. My converted dates are now in the 1970s… Seems like Bubble suddenly decided that this should work for timestamps in milliseconds and not the one in seconds. Is anybody else having issues with this? PS: apparently you could simply use …

[adamhholmes]

What’s the API?

[demondragong]

Thanks for creating a dedicated post. Not sure it makes sense for me to report a bug as well?

In my case the API is Chargebee, which returns timestamps in seconds. I believe Stripe is an even more widely-used API that returns timestamps in seconds.

Seems quite bold to suddenly change the behavior of the date (UNIX) API response filed type (before a 3-day weekend…). From the other thread you can see that it’s been behaving this way (converting timestamps that are in seconds into bubble dates) since at least 2021, and that users could already convert timestamps that are in milliseconds using the date field type.

It’s breaking things in production. In the last working hour on Friday afternoon already 9 customers didn’t receive the quote they expected. I hope this gets resolved by the end of the weekend… That’s just our story but I imagine we’re not alone.

[hassan3]

All the APIs that I have return UNIX in seconds and all have been working fine so far until yesterday.

I’m using Stripe, Instagram API, and a couple others.

All API responses remain unchanged. Its Bubble that has a bug.

[hassan3]

@demondragong

It’s breaking things in production. In the last working hour on Friday afternoon already 9 customers didn’t receive the quote they expected. I hope this gets resolved by the end of the weekend… That’s just our story but I imagine we’re not alone.

Same here. Crashed the entire web app for me. Lost lots of orders, got many customers who cancelled their service with us.

And - Bubble is non responsive to the bug report that I submitted.

I had to resort to a datetime plugin, and have got it to work. I don’t think Bubble will respond to the bug anytime soon.

[sudsy]

@hassan3

Simple Workflow -

API Call → Get Timestamp (UNIX) → Create New Thing in DB

Issue is date is getting saved as 1970.

Hey @hassan3,

I was going to try to replicate this issue. Can you elaborate on the Get Timestamp (UNIX) step?

If the type for the timestamp field is set to date (UNIX) in the API Connector, then the value the Bubble editor “sees” should be a regular Bubble date type. As such, I don’t quite understand the reference to Get Timestamp (UNIX) when saving to the DB (assuming the DB field you’re saving the value into is of type date).

Thanks for the clarification.

[bubbleadmin3]

Hi @sudsy.

I believe what @hassan3 means is getting a date from a timestamp in an API response, like in the following image.

Bubble used to calculate that date assuming a timestamp in seconds, but it’s now assuming milliseconds.

Let us know if that’s not what you meant Hassan (just taking my chances here, as this is a pressing issue).

[hassan3]

@bubbleadmin3

Let us know if that’s not what you meant Hassan (just taking my chances here, as this is a pressing issue).

Yes, this is exactly it.

Here is a simple way to test this -

Setup API Connector
Make an API Call to any endpoint that gives UNIX timestamp [Stripe, Instagram, etc]
Within API Connector - when you initialize the call, within the pop-up mark this UNIX response as ‘date (UNIX)’
Now, with a workflow, when you get response from API, save this ‘date’ into a table (the field is set as ‘date’) and it will come up as 1970

And this is a sudden, uninformed change done by Bubble. It was working flawlessly for ages.

[ltapps]

Here I confirm I found out hard way. All my events which I fetch from 3rd party start in 1970. So yes Bubble has 100% bug with unix / api connector. Serious bug. Its really easy to reproduce with API get unix date and everytime you will get same date and it is 21. January 1970. API is TicketTailor Ticket Tailor API | Ticket Tailor
e.g. next_occurence_date - unix

[sudsy]

Ok, thanks for the clarification, guys. That’s what I thought was meant. I agree it’s a major issue. Unfortunately, I’m unable to reproduce it. I’ve tried making the call from both a frontend and backend wf, and I get the expected result.

I’m puzzled as to what’s different about my setup. In an effort to distill things down to the simplest working example, I’m making the API call to my own app, but that shouldn’t matter.

 
 
I guess it’s possible the code changes are part of a gradual rollout so as not to impact the entire Bubbleverse if there are any issues. Maybe I’m in the cohort that hasn’t seen the changes yet.

Just for the halibut, has anyone tried reinitializing the API call to see if that remedies the issue?

[demondragong]

Thanks for the suggestion. Re-initializing the call did not work for me, neither did recreating a similar call.

But it made me narrow down the bug, which seems to only affect responses that are lists / where the dates are nested in the response.

That might be why it worked on your side @sudsy

[courtlend]

This same issue hit my app. I opened a support ticket 2 days ago before there were any posts on the forum about it. Support confirmed they could reproduce / see the issue in my app and said they forwarded it to the appropriate Bubble team for investigation (but that team only works Mon-Friday) and with Monday a holiday in the U.S.A not sure when it will get seen. So debating if I wait and hope they fix it soon or try and augment it with a 3rd party plugin…

[hassan3]

@sudsy

Just for the halibut, has anyone tried reinitializing the API call to see if that remedies the issue?

I tried everything possible -

I deleted the API call from the API connector, and set it up fresh all over again.

Tried to re-initialize several times.

I even thought maybe the endpoint changed their API response so I cross tested with 3 different APIs - compared the response to old data I had saved somewhere - and confirmed no API responses have changed either.

//

Still no response from Bubble regarding my bug report. Hopefully they reply to one of you guys.

[hassan3]

TEMP FIX

Use SecondsToDate Plugin

In your workflow -

API Call → You Get Response → You Add to DB (but here for the ‘date’ field in your DB, put ‘get data from external API’ and choose SecondsToDate (insert dynamic value from your API response) and then you’re good.

Not an ideal fix but we have no other option.

[sudsy]

@demondragong

seems to only affect responses that are lists

Ahh, great info. Yes indeed, I can now see the problem when using the following API data…

The first one gives the expected result when marked as date (UNIX), but the one in the list does not. BTW, the issue manifests even when displaying data straight from the API on the front end.

Pure Bubble Workaround

Following is a “pure Bubble” workaround. Conceptually, it’s quite straightforward (and has the same effect as the plugin). Just use number instead of date (UNIX) for the timestamp fields when initializing the API call and then add add that value to the UNIX epoch, which has a timestamp of zero.

Here are the steps…

1. Make sure the timestamps in the API data are initialized as type number instead of date (UNIX).

2. Go to the EpochConverter site and enter zero next to the button labeled Timestamp to Human date. That will give you the local time which corresponds to a timestamp of zero. Stated another way, it gives you the UINIX epoch expressed in local time.
    
   

   

3. Enter the value you see for Your time zone into an option of type date.
   

   
   
    
   IMPORTANT: Do not enter exactly what you see in the screenshots above, but rather what appears for you when you enter zero into the input on the EpochConverter site. The date and time you enter will depend on your timezone, but the value saved - i.e. zero - will be the same regardless of your timezone. The idea is to get a date with a timestamp of zero into your app.

4. Now just use an expression like the following before displaying or saving the date value.
    
   UNIX Epoch’s Value+seconds:timestamp_as_number_from_api
    

This will continue to work after a fix is deployed, but of course, you should revert the workaround at that time, which will require reinitializing the call and updating the expressions.

This approach may or may not be easier than the plugin, but it comes with the bonus of now having a reference to the UNIX epoch in your app, which might come in handy in the future.
 

@fede.bubble if you think this thread could expedite a fix, please point the Bubble team to it.

[demondragong]

Thank you so much for taking the time to look into this and suggesting this workaround. It is a simpler solution than what I was about to do.

The irony is that I used to do timestamp to date conversion this way but it felt very hacky and laborious if you have many dates.

I was happy when I found out that Bubble could do it in the API connector.

It didn’t seem right to have to rely on such tricks or install a plugin for something as common as that.

[l.patone]

Bubble team is working on this bug or we have to apply the workaround?

[l.patone]

I confirm that, since yesterday, all UNIX dates in seconds are not recognized anymore.

[l.patone]

I’m deeply concerned about the lack of response from the Bubble Support team regarding this bug. It’s been several days since this issue was first reported, and many users (including myself) have submitted support requests without receiving any meaningful updates or resolution.

This is not a minor inconvenience—our apps are currently unusable due to this bug, as critical workflows relying on UNIX timestamps are failing. It’s unacceptable for such a serious issue to go unresolved for this long, especially considering that this is clearly a platform-level bug and not an isolated case.

Here’s what makes this even more frustrating:

1. Multiple users have confirmed this issue in the forum, showing it’s not specific to any app.
2. The problem has rendered core functionalities of many apps completely broken, which is a major disruption to businesses relying on Bubble.
3. We’ve provided sufficient evidence (screenshots, test cases, etc.) to demonstrate the bug, yet there’s been no visible progress or acknowledgment from Bubble Team.