.ToShortDateString returning different cultural format than expected

Question

Here's a weird one for you.

We've got a c# interface that's been running since the beginning of the year without problem on a windows XP (32bit) PC. We've just upgraded the PC to windows 7 (64bit) with apps installed by SCCM.

With the latest run the dates in the text area have started appearing in US format (5/2/2014) instead of UK format (02/05/2014).

The code that is being used is:

string Lines = FromFormat.Text + " from " + FromFormat.Charge_From.ToShortDateString() + " to " + FromFormat.Charge_To.ToShortDateString() +".";

Where FromFormat is an object with the source data, Charge_From & Charge_To are DataTime variables.

We've checked the PC's regional settings and created a little test app to display the pc's settings from .Net both of these are set as UK formats Code for test app:

label1.Text = DateTime.Now.ToString();
label2.Text = DateTime.Now.ToString("dd MMM yyyy");
label3.Text = DateTime.Now.ToShortDateString();
label4.Text = Thread.CurrentThread.CurrentCulture.EnglishName;

I know that I can replace the ToShortDateString() with a ToString("dd/MM/yyyy") to force the correct format but my question is why is this happening?

Is it something to do with the windows 7 upgrade? or the SCCM?

Thanks in advance

Anatomize

What is your CurrentCulture? Is it en-GB or en-US? – Vilify

"I know that I can replace the ToShortDateString() with a ToString("dd/MM/yyyy") to force the correct format" That's not correct, ToString("dd/MM/yyyy") will also use your curent culture's date-separator instead of /. – Prop

As far as I can tell all PCs are using en-GB – Anatomize

Answer 1

After much testing and scratching of heads we think we've found an answer to this.

During the testing we noticed that PC’s that had had the interface installed via SCCM (windows 7 only) were producing the US date formatted text but those that were via Click Once directly (predominantly XP) were producing UK date formatted text.

Further testing confirmed that if we installed a Windows 7 PC via Click Once we got UK date formatted text.

Following a lot of confusion, we noticed that when SCCM installed the interface it was installing the RTM version of the Report Viewer but when Click Once was installing the interface the SP1 version of the Report Viewer was installed.

We altered the SCCM to install Report Viewer SP1 and tested a new SCCM installed version of the interface and got UK dates.

Why the version of Report Viewer would affect the culture settings of a PC or how ToShortDateString() works, we have no idea but this appears to be what the issue is.

Anatomize

Answer 2

ToShortDateString method uses ShortDatePattern property which is identical of "d" standard date and time format of your CurrentCulture.

en-GB culture's ShortDatePattern property is dd/MM/yyyy.

But en-US culture's ShortDatePattern property is M/d/yyyy.

That's why you can't always replace with ToShortDateString and ToString("dd/MM/yyyy"). They are not always the same. And "/" Custom Format Specifier has a special meaning as replace me with the current culture or specified culture's date separator.

I suspect your regional settings changed on your upgrade process and that's why ToShortDateString method generates different results.

But since you didn't tell us your CurrentCulture, we never know what the real problem is..

Zoochore

My first thought that the regional settings had changed, but they are set to English (United Kingdom) which is the same as how the XP pc's are set. – Anatomize

The weird thing is that when we run the test program on the PCs it report that the pc is English (United Kingdom) but when you run the interface a few seconds later it writes the date out in en-US format. we've already found that in Windows 7 there are multiple places where ODBC are stored/accessed is there something similar for the regional settings? – Anatomize

@Anatomize So your CurrentCulture property is en-GB? Run in your program and see. – Vilify

just checking, when you say CurrentCulture do you mean via the Thread.CurrentThread.CurrentCulture? If so then based on the test program both the Windows 7 & XP pcs are returning en-GB. while stepping through the code on XP en-GB is returned. We don't have a Windows7 development PC to step through on. – Anatomize

@Anatomize It was System.Globalization.CultureInfo.CurrentCulture actually. If it is en-GB, it is too normal to print as dd/MM/yyyy format. – Vilify