windows phone date parsing problems in Italy
62

PSA: Windows Phone users in certain regions may be experiencing date bugs in their apps - workaround identified

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.

1
loading...
0
loading...
50
loading...
0
loading...

Comments

There are 62 comments. Sign in to comment

l_n says:

Can anyone confirm if this is restricted to the WP8 SDK or is a bug in .NET 4.5?

Jay Bennett says:

I'll try and fire up my Lumia 800 now (battery is dead) and see if I can replicate it on WP7

Buon lavoro Jay (if Bing translate did it right), interesting date issue

CommonBlob says:

Sounds odd, and from this article im still not sure of the problem :) But I'm not in Italy so ho hum!

WPenvy says:

MyAuto too. Can't backup my database to Skydrive

wiscamper says:

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.

rth314 says:

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.

Jay Bennett says:

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

trashr0x says:

yup, that's a good way to go about it

operand says:

Or use tryparse which is more a safer way to handle exceptions. Date time.tryparse.

Jay Bennett says:

Absolutely right, I wrote that code years ago before I learned much better practices

PeterFnet says:

Still trying to find a way to bring back yyyy-mm-DD

gfunk84 says:

I have no idea why they removed the ability to choose your own date format like WP7. A step back.

olivercorb says:

sorry to go off-topic, but what dock are you using there for the 8X? been looking for a good one for ages!

mlcooper54 says:

olivercorb - looks like a black Nokia DT-910 Wireless Charging Stand. I have the white version.

Jay Bennett says:

Correct, just a good stand for the picture, wireless charging only works if you have the Verizon one though

olivercorb says:

Damnit. No wireless charging in my uk model. Considering hacking my old palm pre wireless charging into this thing if no Verizon back covers come on the scene...

220SeaChaser says:

I was wondering the same thing and then remembered I have a Ballistic case on my 8X..... :-\

mlcooper54 says:

220SeaChaser - I have an OtterBox Defender on my L822 and it charges perfectly on the wireless charging stand.

220SeaChaser says:

Ahhh. I didn't see the "wireless" part. I thought it was a dock with plug-in. My bad. Thanks!

The_Traveler says:

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!

jsnod25 says:

Maybe not everyone is as good as you... Considering the fact its not limited to one app... I still think the march 1st thing indicates a separate issue here, but I'm not as good as you either.

AngryNil says:

Let me guess: you write machine code? Oh, you don't? Why are you relying on programming languages to babysit you? This is ridiculous!

rth314 says:

Dude, you are rediculous!  Have you ever had a bug in your code?  If not, then you haven't coded anything!

Jay Bennett says:

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.

The_Traveler says:

Lol ok fair enough Jay, I was a bit of a dick. The app, website and podcasts are great. Just the parse thing is not something I would rely on, but that's me.

This is Finland's way of getting back at Italy for WWII :D

MrA2Z says:

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)

Ordeith says:

Best explanation I have seen. Makes sense too.

astroXP says:

March (month) in Spanish is «marzo»

MrA2Z says:

Sorry double post. This edit is not working properly in firefox, don't know about other browsers...:)

MrA2Z says:

I hate implementation of tabs in Internet Explorer, so don't use it. Chrome was giving lot of errors on websites which use flash e.g youtube so I stick to Firefox.

gfunk84 says:

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.?

Jay Bennett says:

It's how the data is coming back to me, we could re-design the feed but I worked with what I had at the time

AndyM72 says:

Jay explained it with this line:
 
In our app, we use this functionality to convert a post's published time to your local time
 
So the app is pulling the text of story posts from WPCentral.com as you can see at the top of this page just under the headline:
 
By JayTBennett, Wednesday, Mar 6, 2013 at 6:13 pm
 
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.

Jay Bennett says:

I agree to an extent, I should have fully specified the date culture and that is completely on me (and other developers have made the same mistake).

AndyM72 says:

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.

Jay Bennett says:

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

Ordeith says:

Couldn't you parse with an English/US culture to get a true datetime object, then reformat that object for localization?
 

insi says:

wpcentral works fine for me, I have that problem with the wmpoweruser app. I am in Germany.

exactly my case here in Greece. wpcentral works fine but wmpoweruser shows no news

AdamDawes says:

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.

Malmer says:

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.

AdamDawes says:

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.)

You need to mind our own business, it works for us, so whatever country you are from, concentrate on it instead of telling us what to do, thanks :)

Xaphoon148 says:

How come the US (and some other regions) still using Thursday 2013-03-07...? Confusing ;)
Think Thursday 07-03-2013 is easier, day-date-month-year

It works for us, and it's the way we know, so there :)

Xaphoon148 says:

Guess it's equally confusing the other way around ;)

Seriously, the Brits still spell words in Old English, should we order them to stop that?  Imperial works for the US, tough noogies there Malmer.

AndyM72 says:

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.

Xaphoon148 says:

And if the Vikings had won the Battle of Stamford Bridge, maybe old Norwegian would be the language... ;)
http://en.m.wikipedia.org/wiki/Battle_of_Stamford_Bridge

msbg says:

Am having the same issue with my app.

Pricop says:

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.

taturo says:

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.
 
 

alfabatsi says:

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.

TexMarine says:

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.