In my web.config file I have this line:
<globalization culture="auto:en-GB" uiCulture="auto:en-GB" requestEncoding="utf-8" responseEncoding="utf-8" responseHeaderEncoding="utf-8"/>
ASP.Net nicely takes care of all date/time formats. Applying the following code in a sample page...
Protected Sub Page_Load(sender As Object, e As EventArgs) Handles Me.Load
txt.Text = New DateTime(2010, 1, 25).ToString()
End Sub
Protected Sub btn_Click(sender As Object, e As EventArgs) Handles btn.Click
Dim dt As DateTime = Convert.ToDateTime(txt.Text.Trim())
Trace.Warn(dt.ToString())
End Sub
With a browser, set to English (UK) I see the date displayed as
25/01/2010 00:00:00
On pressing the button and converting this back to a DateTime value, it works perfectly.
If I change my browser (Chrome) settings to Norwegian Bokmal, and load the page, I see this:
25.01.2010 00.00.00
This again is correct, but, if I then submit the form, ASP.Net crashes:
String was not recognized as a valid DateTime.
Line 9: Dim dt As DateTime = Convert.ToDateTime(txt.Text.Trim())
Why is this happening? Surely if ASP.Net has the sense to display dates based on culture settings, it should be able to read them? I've tried English UK and English US and both work as expected, plus others, so it seems linked to Norwegian in some manner.
Finally found the answer. It is a bug in the .Net framework for v4.0+.
It has been reported in Microsoft Connect, and a temporary workaround is detailed here. Apparently this is problem strictly related to Windows 10:
Windows 10 changes the date and time formatting settings for some cultures. Of particular concern are seven cultures for three different regions:
- Finnish
- Norwegian Bokmål (“Norway” and “Svalbard and Jan Mayen” variants)
- Serbian (variants “Cyrillic, Kosovo”, “Latin, Montenegro”, “Latin, Serbia” and “Latin, Kosovo”).
For these seven cultures, Windows 10 changes the date and time separators to be the same. For example, in Finnish, the standard date format used to be 26.8.2015 21:08, while it is now 26.8.2015 21.08 – note the subtle change in the time separator.
In all currently released versions of .NET, the DateTime.Parse method has a shortcoming: It always fails to parse a date or a date+time combination in a culture where the date/time separators are the same character. This bug, together with Windows 10’s culture changes, breaks the previously hard rule of DateTime.Parse always being able to parse the culture’s default DateTime representation. Now, DateTime.Parse(DateTime.Now.ToString()) no longer works under the described conditions. Neither does DateTime.Parse(DateTime.Now.ToShortDateString()), which is somewhat counterintuitive since the changed time separator isn’t even involved, but true nonetheless – the parser thinks it’s parsing a time instead of a date.
An official patch will be released in September 2015.