Date Parsing Issue – Inconsistent Output for

Forum|Forum|1 year ago
July 1, 2025
5 replies
176 views

I'm running into an issue with date formatting in my email templates.

In my payload, I’m receiving a date string in the format MM/DD/YY, for example: "newShippingDate": "07/09/25"

I'm using the following code in my template to format the shipping date based on region:

{% if c.newShippingDate %}
<br>Estimated Shipping Date:
{% if region|lower == "uk" %}
{{ c.newShippingDate|datetime_from_string|date:"d/m/Y" }}
{% else %}
{{ c.newShippingDate|datetime_from_string|date:"m/d/Y" }}
{% endif %}
{% endif %}

region = ‘us’, In one preview, the date renders correctly as 07/09/2025 (July 9, 2025), but in another preview, it's showing as 07/08/2025 — which suggests the date is being misinterpreted.

Best answer by JaydeepPatel

Hey @Byrne C - I dug deeper into the issue, and here are my findings:

When using: {{ "07/09/25" | datetime_from_string }} the output shows “July 9, 2025, 5:30 a.m.”.
This is because the datetime_from_string filter applies timezone conversion. It first interprets the value as July 9, 2025 at midnight (UTC), and then adjusts it based on the customer’s profile timezone.

In this case, the profile timezone is Asia/Kolkata (UTC +5:30), so the timestamp shifts to: July 9, 2025, 5:30 a.m.
When using: {{ "07/09/25" | format_date_string }} the output is “July 9, 2025, midnight.”
The format_date_string filter only formats the date—it does not apply any timezone conversion.

Byrne C

Community Manager

Hey @JaydeepPatel,

In the preview where you’re shown 07/08/2025, what’s the {{ c.newShippingDate }} property in that specific profile/event? Additionally, does their region|lower property equal uk? If not, it would make sense that you’d see the date appear as 07/08/2025, based on the logic you shared.

That being said, I’m happy to look into this a bit more! A couple more screenshots of how the preview email appears, and the relevant event data that feeds into this specific preview would be helpful for us to get to the bottom of this!

J

JaydeepPatelAuthor

Problem Solver I

Attaching the screenshot for you.

In the payload : newShippingDate:07/14/25 and region : us

Date rendering in email based on above code : 07/13/2025

Thanks! Jaydeep Patel

Byrne C

Community Manager

Thanks for sending that over. It would be really strange for the newShippingDate variable to show as 07/13/2025 when the shipping date in the event data is something different. You can confirm that you copied the correct variable and added it to the table, correct?

If so, could you try making another table and seeing if the correct shipping date shows up in that one? This would help us check and see if the issue is related to a cacheing error in the other table.

Finally, if none of this works, I’d recommend reaching out to our support team at Klaviyo.com/support. They can take a look at the actual template to determine why this is happening.

J

JaydeepPatelAuthorAnswer

Problem Solver I

Hey @Byrne C - I dug deeper into the issue, and here are my findings:

When using: {{ "07/09/25" | datetime_from_string }} the output shows “July 9, 2025, 5:30 a.m.”.
This is because the datetime_from_string filter applies timezone conversion. It first interprets the value as July 9, 2025 at midnight (UTC), and then adjusts it based on the customer’s profile timezone.

In this case, the profile timezone is Asia/Kolkata (UTC +5:30), so the timestamp shifts to: July 9, 2025, 5:30 a.m.
When using: {{ "07/09/25" | format_date_string }} the output is “July 9, 2025, midnight.”
The format_date_string filter only formats the date—it does not apply any timezone conversion.

Thanks! Jaydeep Patel

Byrne C

Community Manager

Hi @JaydeepPatel,

Thanks for coming back and sharing your findings! This’ll be helpful for people to reference in the future!

Sign up

Use your Klaviyo credentials

Log in to the Community

Use your Klaviyo credentials