Issue in date handling in Blue Prism 7.4

[Federico.Tobares]

Hi community,

I'm currently migrating processes from Blue Prism 6.10 to version 7.4 and encountered an unexpected behavior related to date conversion.

In previous versions, I was able to assign a date string in the format dd/MM/yy (e.g., extracted from a website) directly to a data item of type Date, and Blue Prism would parse it correctly.

However, in version 7.4, doing the same results in a conversion error or an invalid format exception. The exact same string that worked before is now rejected.

Has anyone else experienced this change? Is there any known regional setting or recommended workaround to force recognition of this date format?

Thanks in advance!

[saha1sourav2]

Hi @Federico.Tobares,

In Blue Prism 6.10, the platform was more permissive with implicit date parsing. When you assigned a string like "31/12/23" to a Date data item, it relied more on the system’s regional settings or default .NET culture settings to interpret the format (dd/MM/yy, for example).

In Blue Prism 7.4, there’s a stricter and more consistent enforcement of date parsing, especially for non-standard formats. This was likely introduced for better stability and internationalization.

Workarounds
1: Use Utility - Date and Time VBO
Use the Format DateTime action in the built-in Utility - Date and Time object:

Action: Format Date Time

Inputs:
Date String: "31/12/23"

Format: "dd/MM/yy"

Output: A valid Date type item

This is the safest and most portable method going forward.

2: Use an Expression with ToDateTime and Culture
You can also use a calculation with .NET functions, like:

=ToDateTime([MyDateString], "dd/MM/yy", System.Globalization.CultureInfo.InvariantCulture)

But note: This only works in Code Stages, not in normal Calc stages. If you're avoiding code, stick to VBOs.

3: Ensure Regional Settings Match
If you really want to use implicit parsing again (not recommended), ensure the machine's regional settings match dd/MM/yy. But:

This is fragile and environment-dependent. Not guaranteed to work in newer versions or during remote executions.

If this help resolve you issue, please mark this as Best Answer. If you still face this issue, please provide more details and supporting screenshots.