ReportViewer WebForms breaks when certain cultures are used in reports with datetime filtering

We've recently upgraded from standalone Report Viewer 2015 runtime to the NuGet package in our ASP.NET webapp (.NET Framework 4.7.2): https://www.nuget.org/packages/Microsoft.ReportingServices.ReportViewerControl.WebForms/

The issue is that using specific cultures, after opening a report that has datetime filtering with a default value (DateTime.Now), the whole Report Viewer breaks on the server (for all users) until an App Pool recycle or IIS restart.

The issue is NOT present in version 150.1404.0 but starts happening from version 150.1427.0 which has a release note "Fixed a datetime parsing issue affecting certain locales." (here: https://learn.microsoft.com/en-us/sql/reporting-services/application-integration/release-notes-ssrs-application-integration?view=sql-server-ver16#15014270).

In 150.1427.0 there is another issue, which results in a NullReferenceException, however in the latest version, 150.1652.0 that is not present, but the reports still won't load as described below.

We are setting parameters like so:

var reportParameters = new List<ReportParameter>();

reportParameters.Add(new ReportParameter("ConnectionString", connectionString));
reportParameters.Add(new ReportParameter("LocalDateTime", DateTime.Now.ToString(CultureInfo.CurrentCulture)));

[...] // Adding some further parameters

_reportViewer.ServerReport.SetParameters(reportParameters);

If the CurrentCulture is set to such a culture that has a datetime format which includes some other characters as the "AM/PM" symbols, but it isn't am/pm or AM/PM itself (for example "a. m." or "GD" or "अपराह्न"), then opening the report works the first time, but at that point ALL other reports for ALL users are broken and won't load on the server.

Some cultures which are known to cause this: es-CO, es-DO, es-MX, ar-BH, syr, syr-SY, vi-VN, zh-TW, ms-MY.

Using Visual Studio to jump in to some decompiled code (hard without a PDB file) we've found that ReportViewer 15 from the version mentioned above tries to interpret and parse EVERY SINGLE PARAMETER as a datetime (even the connection string or the user ID, etc.):

ServerReport.cs:

public override void SetParameters(IEnumerable<ReportParameter> parameters)
{
[...]
    while (enumerator2.MoveNext())
    {
        string value = DateTimeUtil.ParseDateToDefaultFormat(enumerator2.Current, CultureInfo.CurrentCulture);
        stringCollection.Add(value);
    }
[...]
    parameter.Values = stringCollection;
[...]
}



DateTimeUtil.cs:

internal static string ParseDateToDefaultFormat(string strDateTime, CultureInfo formatProvider)
{
[...]
	if (m_serverDateTimeDesignator != "" && !strDateTime.EndsWith(m_serverDateTimeDesignator) && array.Length > 1)
	{
		return string.Join(" ", array, 0, 2) + " " + m_serverDateTimeDesignator;
	}
	return strDateTime;
}

ParseDateToDefaultFormat() gets called for every single parameter, regardless if it is a datetime or not. Then inside that function a static variable called m_serverDateTimeDesignator will be set after opening the first report to contain the special characters mentioned above. The reports break afterwards, as if that variable is set, it will result in all the input parameters being changed to garbage data (if they contain any space).

(We think that opening a report with a datetime filter parameter is also a prerequisite for triggering this issue, because that is when Report Viewer will set the value for m_serverDateTimeDesignator, but this is not verified.)

For example, the connection string becomes "Data Source=localhost;Initial a. m." when line "parameter.Values = stringCollection" runs, instead of an actual, proper connection string that was passed by our server code.

And because m_serverDateTimeDesignator is a static variable, it will keep its value for ALL reports, ALL users until a recycle / restart, thus making reports fail to load due to the wrong connection string. (Even if that is fixed manually during debug, all other parameters that have a space in them will contain "a. m." or similar as a postfix.)

Cultures that don't contain anything else than numbers and separator characters or only contain "am/pm/AM/PM" still display this behavior of parsing everything as a datetime, they just happen to keep working because m_serverDateTimeDesignator will never be set and when it remains an empty string, ParseDateToDefaultFormat() will just return the original value as can be seen in the code above (for problematic cultures, after m_serverDateTimeDesignator is set, it will instead do the string.Join() line).

Could you please help in verifying this is an actual issue with Report Viewer or if we can fix it by modifying our code?

Thanks in advance!