Streaming live at 10am (PST)

CMS date fields emit as UTC dates in HTML Embeds

Hi guys, date fields in the CMS are emitting as UTC dates in HTML Embed elements. It breaks our sites since I happen to be managing projects in New Zealand at the moment - GMT+12.

Here’s a demonstration-

It looks like a similar problem was fixed earlier this year with regards to the primary HTML output, and that’s been fixed to localize the date based on the site’s specific timezone settings. However somehow that was missed in HTML embeds.


A fix around dates import have been pushed this week. Previously import of dates was a bit hard as you had to add 3 to your usual offset. For example I had to import YYYY-MM-DDTHH:MM+04:00 to add a GMT+1(UTF+1) time.

But this is fixed since thursday. And I learnt that WF only stores the dates in UTC. So anything you type in or import is converted to UTC depending on your site’s timezone settings. Then WF uses the timezeone to display the correct time within CMS backend, designer and on publish.

So that’s the reason UTC time shows up, I guess. It’s probably a bug where the timezone isn’t applied to what Webflow stores.

I’m sure it will be addressed.

Hi @Brando! Do you see this? :slight_smile:

1 Like

Thanks Vincent, that jives with what I’m seeing-

I’m able to hack the WF field codes in the HTML Embed, to generate the ISO-8601 formatted dates I need for JSON-LD. The hacked code looks like this;

Here’s a sample event, displaying with the correct locally-adjusted datetime;

Here’s the datetime emitted by the HTML Embed using my hacked 8061 formatter.
The difference is UTC+13 which is correct right now for New Zealand.


1 Like

@vincent Can you tell me roughly when the HTML Embed can be fixed to emit the correct local datetime? That’s the last piece I need for Google’s Rich Cards. Thanks for looking at this.

Oh sorry no I can’t. I’m not working for Webflow, I know nothing about the roadmap and I’m not part of any beta test atm. I have pinged @Brando so I’m sure they’re aware of this at least.

1 Like

Hi @memetican Thanks for posting and thanks for chiming in @vincent :slight_smile:

This definitely looks related to the update we pushed that Vincent mentioned. I have reported these findings to the team and we will investigate further.

I’ll post back as soon as I have more information for you!


Hi @Brando can you give me an ETA on when this will be repaired? My client is asking me to give them a launch date for the site.


Hi @memetican

Thanks for following up with this issue.

I just spoke with our team on this and we found the root cause of the issue. We are still working out a solution for it, and hope to have it soon. I’ve also notified the team that this is blocking you and your client.

We looked into workarounds to see if we could provide a temporary patch while the team finds a permanent solution, but unfortunately we weren’t able to find any practical ones.

I’ll notify you as soon as I have another update on this!

Thanks Brando, we’re ready to launch and looking forward to it- happy new year to you and the team as well!

Hi @Brando, checking in again. We were hoping for the Jan 1 launch but I’ve told them you’ll hopefully have it fixed by Feb 1?

Hi @memetican

Thanks for pinging me on this issue. I checked with the team and we may be able to have this issue resolved before then, but I cannot say for sure.

We will do our best to get this resolved quickly for you.

Thanks for your patience!

Hi @memetican

Thanks so much for your patience with this date fields issue.

Our team pushed a fix for this and CMS-bound dates should now show as expected in HTML embeds.

Can you please check this on your end to see if this is resolved?

​Thanks in advance, and I’m standing by for your reply.

Thanks Brando! It’s looking good- the correct datetimes are emitting now.
We’ll push it into production and let you know if anything weird happens.


1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.