Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BindingParameterResolverTests fails in most locales #2959

Open
pjt33 opened this issue Feb 16, 2023 · 0 comments
Open

BindingParameterResolverTests fails in most locales #2959

pjt33 opened this issue Feb 16, 2023 · 0 comments

Comments

@pjt33
Copy link

pjt33 commented Feb 16, 2023

The unit test BindingParameterResolverTests.DateTimeResolver_ReturnsExpectedValue is locale-dependent and shouldn't be.

Repro steps

  1. Switch to a locale such as en-GB.
  2. Set the date to a date on the 13th or later of the month.
  3. Run the unit tests.

Expected behavior

The unit tests should pass.

Actual behavior

DateTimeResolver_ReturnsExpectedValue fails with a FormatException.

Microsoft.Azure.WebJobs.Host.UnitTests.Bindings.Path.BindingParameterResolverTests.DateTimeResolver_ReturnsExpectedValue
  Source: BindingParameterResolverTests.cs line 68
  Duration: 1 ms

Message: 
  System.FormatException : String '02/16/2023 08:35:41' was not recognized as a valid DateTime.

Stack Trace: 
  DateTimeParse.Parse(ReadOnlySpan`1 s, DateTimeFormatInfo dtfi, DateTimeStyles styles)
  DateTime.Parse(String s)
  BindingParameterResolverTests.DateTimeResolver_ReturnsExpectedValue() line 77

The problem is that resolvedValue = resolver.Resolve("datetime:G") uses CultureInfo.InvariantCulture, but the basic DateTime.Parse(resolvedValue) of the following assert uses whatever the current culture of the test computer is. For historical reasons CultureInfo.InvariantCulture is, if not an alias of en-US, very close to it, but the majority of cultures don't use middle-endian dates.

Known workarounds

Setting the computer's locale to en-US is a workaround, but somewhat antithetical to the desire to welcome outside contributions.

I see this as a bug in the test rather than the code tested, so I think the correct fix is to change DateTime.Parse(resolvedValue) to DateTime.Parse(resolvedValue, CultureInfo.InvariantCulture).

Related information

Present in e210142 , which is the current dev.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants