Hi,
Since a few days/weeks I’ve had issues with formatting dates and times in my e-mail components.
For example this line:
{% set start_time = contact.timestamp|format_date(‘h:mm a’,‘Europe/London’,‘en-GB’) %}
give me this error:
104:0 com.hubspot.jinjava.interpret.Interp e a date object, was: class java.lang.String
This has been working flawlessly for 12-18 months, but suddenly it doesn’t work anymore.
I’ve tried to use strtotime, unix timestamp and different ways to get it working again. Using |render worked for a bit but stilll I have no working solution for something that used to work and that should be trivial.
Additional confusion is that I use these timestamps in multiple e-mails, and even though the Design Manager gives me errors (and blocks me from saving) it still works in the production e-mails going out to customers, but NOT IN ALL e-mails.
Do you know if there has been any recent changes on the date or datetime objects?
Or know any other thing that could be wrong with this?
//Anton
Hi @antonjarl,
Thank you for posting to the Community!
I’d like to tag in some of our Subject Experts to see if they have any ideas on this one -- Hi @Gonzalo @ChristinaKay and @WesQ Do any of you all have any suggestions for @antonjarl?
Thank you!
Cassie, Community Manager
Hi @antonjarl, I can’t explain why this would have been working for the last 12-18 months, but I believe that HubL filters (like |format_date) are not supported for use with personalization tokens in emails, see documentation here.
I haven’t tried it in a while but you might be able to use functions like the formate_datetime() function instead?
Hi,
I get an error when trying to use the function as well:
• 5:0 Error invoking function ‘format_datetime’
The weird thing is that the same code works in another component. I still get the error in Design Manager since some time back, but it works and the e-mail gets delivered to the customers correctly, but for this other component it doesnt.
But if this isn’t even supposed to work in the first place, what is the correct way of doing this?
I have a datetime object on the contact, that we want to communicate to the customers through e-mail.
* Custom code nodes in the flow that converts them to strings?
* Workflows in Hubspot that creates a string version of the datetime object?
Both of these seems like more work that what should be needed, and using custom code nodes also makes it hard to preview the e-mail..
Hey Anton, the error is coming from `contact.timestamp` being returned as a string in that rendering context rather than a native date object, and `format_date` won’t accept a string directly.
The fix is to pipe it through `strtotime` first with a pattern that matches what HubSpot is actually giving you back, then into `format_datetime` (not `format_date`).
Something like:
`{% set start_time = contact.timestamp|strtotime(‘yyyy-MM-dd’T’HH:mm:ss.SSSZ’)|format_datetime(‘h:mm a’,‘Europe/London’,‘en-GB’) %}`
Worth logging `{{ contact.timestamp }}` raw in a test first to confirm the exact string format, so the `strtotime` pattern matches correctly.
Full filter reference at https://developers.hubspot.com/docs/cms/hubl/filters
The inconsistency across emails is almost certainly null values. HubSpot changed how `strtotime` handles nulls in late 2024, it no longer silently returns the current date when the input is empty, it returns null instead. So contacts with the field populated still render fine but contacts missing that value now fail differently, which would explain the partial breakage.
The Design Manager also validates these filters more strictly than the actual email renderer, which is why save gets blocked even when production still goes out. I run into this kind of HubSpot rendering discrepancy fairly often through the integrations we work with at Stacksync .
Adding a null guard like `{% if contact.timestamp %}` around the whole block should stabilize the inconsistency. Hope that sorts it.
Hi,
Thanks for the reply. What you write aligns with my observations as well. I’ve worked around this for now by passing in the data in the correct format from the workflows instead through custom properties. It’s not as elegant, but at least it works reliable now. I’ll take a look at re-solving it with your idea now and see if we can revert back to components that “just works” without having data-formatting nodes in each and every workflow.