formatDate output is wrong (sometimes)

Dear Makers!

When using {{formatDate(now; “DD/MM/YYYY”)}} in a variable the output is correct. When doing the exact same to format a field in MailChimp the output date is wrong by a few months. Adding the timezone does not make a difference.

Any ideas?

This issue also affects filters. So when filtering for a date that is within the last day, it does not pass the correct ones.

Hey Steven!

If you’re using a Date filter condition or if MailChimp expects a Date as the value, you should not format it. Just pass the date as-is otherwise it might be interpreted as MM/DD instead of DD/MM.

I hope that helps!

1 Like

Hi @Bruno_T ,

Thank you for your answer. In MailChimp you can choose the date format. I’ve never had any trouble with this before in MailChimp.

Best, Steven

Hey Steven!

If the field you’re trying to fill out is of date type, please try my suggestion and hopefully that should work fine. Same thing for filters.

image

If not, I’d say this is pretty hard to diagnose without your logs, so I’d recommend reaching out to our support team by creating a ticket if you need additional assistance.

Thanks!

1 Like

@Bruno_T Thank you for your reply. It turns out that using it as-is does work for MailChimp. Filtering is a different game, because I think I need to match the condition input format with desired value. See screenshot. How would that work without formatDate?
BUas-Alerts-met-opl-22-23-Make

Datetime fields will compare datetimes. Your format function is converting the datetime value to a number, so if you wish to use timestamps you should be using numeric filter operators instead.

I hope this clarifies your doubts!

@Bruno_T Surely that can’t be right? This filter has always worked in the past. Also, when I run it now it works once. Run the scenario once more, it stops working.

I can’t really troubleshoot this further without more details, but formatting a date with the X parameter will output a number, so I would recommend sticking to numeric operators in that case, or using the non-formatted, “raw” date value instead.

It’s true that we will coerce the timestamp into a date, but as far as I can tell this could be a timezone difference and not necessarily a bug, so without knowing the values of those variables and more contextual information like the timezone of your organization, I can’t really say what could be wrong.

If _attributes.moment is not formatted as an ISO date, formatDate will first attempt to parse it into a proper Date and then format it. This could introduce issues with type coercion, especially when dealing with timezones or depending on the format of the input.

I would need more information to properly troubleshoot this, so if you still run into issues or have further doubts, I would recommend reaching out to Make Care directly by creating a new ticket.

1 Like

Hey there @Steven :wave:

I was wondering whether you had a minute to check out @Bruno_T’s suggestion.

If you did could you share your progress with us? This way our community stays tidy and neat for other users :broom:.

Thank you!