1

We have a few environments for our product: Development, Quality Assurance and Production. When browsing a site hosted on the Dev environment, the date format is yyyy-MM-dd on QA & Prod, it is yyyy/MM/dd. The decimal point on Dev is . while the decimal point on QA & Prod is ,.

I've seen questions like this, this and this that refer to the .NET Globalization at the app-level. In each of our web-applications, the following line exists in the web.config, (Client Based Culture is also set to False):

<globalization culture="en-ZA" uiCulture="en"/>

All three servers also have the same regional settings, the OS-level date format is yyyy-MM-dd and decimal symbol on all three is set to .. How is it that the date formats AND the decimal points differ on the sites only? In the OS, the formats all match each other e.g. in Excel / System Clock.

This is causing problems with automated testing as the asserted values are often incorrect given the format difference. We can adjust our test fixtures but this isn't a solution to the underlying issue.

2
  • 1
    I'm inclined to think this could be the app. Unless there is something in machine.config. And this is still a bit murky, as it seems it could be the text as rendered from the server within an element has the wrong format, or some other type of more complex date control is rendering wrong on the client. Also, non-ui culture, unless this is a commercial app that is going to customers, should be hard-coded in the app, not in the config file. This is because even something benign like calling DateTime.ToString() can throw an exception if the culture is set to an unexpected value.
    – Greg Askew
    Aug 29, 2021 at 11:48
  • Thanks for the input @GregAskew dynamically setting the culture hadn't been a material issue in the past, given similarities in culture for our users, but it seems it's something we need to address.
    – Daniel
    Aug 30, 2021 at 13:12

0

You must log in to answer this question.

Browse other questions tagged .