Windows Phone Central's app support inbox has been flooded recently, by users complaining that news does not load correctly in the app. We've been kind of stumped on this one frankly because it's only been affecting certain users, so we've been digging.

It turns out that other apps were also running into problems (WeatherFlow is one example), and as we dug further we identified that most of the affected users were Italian, and that the issue had started on March 1st. Now, thanks to twitter user @SergioPedri and others in our forums, we've finally been able to replicate the problem. The good news is there's a workaround.

To keep this post from being too technical, there is a very common function in the C# language; DateTime.Parse(string). This function allows you to enter a formatted string of text and in turn receive a DateTime object which can then be manipulated within your software. In our app, we use this functionality to convert a post's published time to your local time, wherever you are.

The problem is, that since March 1st, when your phone is set to the Italian region, this method throws a "FormatException" (South Africa also appears to be affected). It works without a hitch for the US or UK (and many other regions), and as I'm not a developer for Windows Phone itself I can't tell you the exact issue, but it's there.

Now I should stress that we should have been handling this problem within the app, and share some of the blame for not handling date parsing with more care. We will release an update as soon as possible to address it, but as the problem started exactly on March the 1st, and we're not the only app affected, we are announcing the workaround publicly to raise awareness.

We've been in touch with the Windows Phone dev team via our channels, but in the meantime you can workaround this bug by going to your phone's settings screen and changing your regional format setting to another option. That setting is under "language+region" if you're struggling to find it. Note that you may need to restart your phone for this to take effect.

We'll keep you updated if we hear any more on this, but hopefully the Microsoft guys will respond quickly to this issue, and if they are unable to, you can contact app developers to let them know about this problem for updates to roll out.

Update: One of our readers 'operand' points out that this issue has also been brought up here on Stackoverflow, confirming that there is a bug that will last throughout the month of March.

Update 2: Re-worded the title of this article in response to ongoing discussion in the comments.

I'm the developer of the MyAuto app and we noticed that errors started occuring with our function to upload files to SkyDrive around March 1st. We do not use the DateTime.Parse function. We rebuilt the app using Live SDK 5.3 which was recently released and now the problem does not appear. It is still a mystery to us.

Don't you need to use the overload where you pass an IFormatProvider so you can let it know the culture of the string you are parsing? If the user has chosen Italian in the settings, then you should be able to pass the Parse method that information so that it will better know how to convert the string to a DateTime.

It should be able to auto detect as the string type we use is a very common standard. Certainly providing a format is best practice, and as I stated in the article I as a developer should have done more when I wrote this particular functionality. However the fact that it broke specifically on 1st of March and was working no problem prior to that means there may be a deeper issue. Several apps are fixed by changing your region so we've put the word out

This is ridiculous. An example of expecting the OS to babysit you. If you had taken the datestamp split it yourself (knowing the expected input format) and created a new date time object using the (y,m,d) constructor this wouldn't have been an issue. Given mobile apps have no borders, you should have been more careful with dates, and not blame the framework!

You are right that is certainly possible. But splitting a string yourself is usually discouraged when there are already libraries to do so for you. Particularly when those libraries are usually faster than writing out your own splitter. Please re-read the article though, I do not blame the framework, i am merely reporting a bug and sharing responsibility.

This is framework related issue. Usually developers use DateTime.Parse(string) to convert the server time to local time. For this they need to find culture specific information which can be done using System.Globalization.CultureInfo class. It gives information about names, writing systems, calendar used and some other culture specific objects which can be used to fomat dates along with some other functions.

The problem starts here when it identifies the region as Spanish or Italian. In Spanish and Italian language translation of Tuesday is Martes and Martedi respectively. Whereas translation of March in Spanish and Italian is Marzo and Marcia respectively. The current implementation of DateTime.Parse(string) is such that when it sees "mar" in the string, it decides that it is day "Tues" which is actually a month. But when it try to parse and finds a day in the place of month, it gives error. Why it reads it Tues instead of March, it is due to the rules defined in this method. I will not go into the technical details.

The problem can be solved by using DateTime.ParseExact(date,format,cultureinfo)

Why even parse date strings instead of keeping dates in property DateTime objects or, if they must be serialized in another format, at least serializing them in a non-culture specific format (e.g. UTC yyyy-MM-dd HH:mm:ss) or as a number of ticks, etc.?

and using the DateTime.Parse to turn this text into a DateTime object. As MrA2Z mentioned, the "Mar" part of this string is being interpreted as Martedi if your phones region is set to Italy. The call is failing with an exception because it thinks it is finding a day of the week where it is expecting a month. Also as he says, the solution is to use a related call that lets you override the region used for interpreting/parsing just this string, since WPCentral.com is "anglophone".

To me, this is not a bug in the framework, this is a lack of understanding of internationalization. Maybe WPCentral.com needs a alternative "feed" that that app can use, where the timestamps are UTC YYYY-MM-DD HH:MM strings.

So are you going to change the title of this news item? Since the issue is that the "date string" from WPCentral.com is for an English/US or English/UK date format culture, and won't ever change, but users of the App could be from anywhere and could change their Location+Region settings to all sorts of things.

So the Parse method to use should have been the one you can hard code to the way WPCentral.com works, not the one that picks up the phone settings.

Which is not a bug in the WP8 OS at all. More like a lack of documentation in the C# docs.

A fair question, the fact that such parsing works in all months other than March still lends itself to suggesting a bug with the way C#'s automatic culture identification works, and said behaviour is present in Windows Phone 8. I have been considering changing the article as it is more of a PSA for users who are using apps which are affected by this problem. The issue is what the title would then change to, especially now that it's been more than 12 hours since it was originally posted. EDIT: I changed the title to reflect the advisory nature of this article

I've been receiving dozens of FormatException [Format_BadDateTime] error reports from Italian RSS Central users over the last couple of days, also all relating to the DateTime.Parse function, I'm glad it's not just me.
The thing that has been puzzling me is that all of the exceptions are coming from my code that reads back dates that have been stored as strings, and they are always without exception stored in ISO8601 format ("yyyy-MM-ddTHH:mm:ss"). As this is purely numeric, I couldn't figure out how the Italian parsing could be any different from any other region. Strange. I've added exception handling for this now but will have to wait another week before this hits the WP Store.

The real bug is everyone not using iso date format. Especially the US. You need to get your s*** together and switch to the metric system and iso dates and times. For the sake of the sanity of the entire planet.

As you can see in my comment above, it is occurring for me when I am using ISO8601 date format. So that isn't the problem. (Though I do agree, anyone storing dates as strings in any other format is asking for problems.)

No, we spell words in English, as in, the language of England. If anyone spells stuff differently, thats their business, but it aint English.
But more seriously, there was no standardized spelling in English until the middle of the 18th Century. Then English (as we speak in the old country) standardised its spellings around the versions in Samuel Johnsons original Dictionary, and about 50 years later, one of our former colonies standardized around a bunch of other spellings catalogued by some ill informed bloke called Noah Webster... which became American English.

I had the exact same issue with my Lumia 800, for example I would receive new text messages/calls and stuff after the bug occured and they were like the middle of the page, older messages appeard top, that was really weird. Glad I swtiched to i5.

I had a problem during wireless charging last night. My L920 turned off while charging, did not charge and it was showing the date august 31. I soft reseted about 3 times and the date kept showing august. While having this issue I took some pictures of my kid when leaving to a trip and the pictures were not saved on my phone. When I noticed about the pictures I tried to reset the phone again and it corrected the date this time. I took some pictures right after the reset and now they were saved in my phone %&?¡"#$% !!!!!!!
I live in Mexico by the way and Nokia has not started selling L920 yet here.
I'm getting tired of all many little issued like this one.............
After all this years Nokia seems to be an amateur on the mobile software bussiness.

It seems that date and time has bug in general. If you change your phone to Georgian region and locale, the week days are shifted. I.e. The date for Sunday, for ex. Would be correct, but the weekday would be Monday. The same problem was observed in windows 8 and office 2013, but the windows 8 got patched, eventually. Still waiting for the patches for office and wp8 though.

FYI, I was having this same issue after the last Here Maps update on my Nokia Lumina 920. I changed the language formate to United States Spanish, rebooted, and then changed it back to United States English and rebooted again. After that, I opened Here Maps and my GPS located me after 10 seconds.