System.FormatException: String was not recognized as a valid DateTime.

[wannabuild]

We're just using Parse for simple push notifications (for now), and we've gotten the following exception(s):

Package: com.myapp.alpha
Version: 1681
Android: 5.1.1
Manufacturer: samsung
Model: SM-G920I
Date: 05/11/2015 13:03:18

System.FormatException: String was not recognized as a valid DateTime.
            at System.DateTimeParse.ParseExact(System.String_s__System.String_format__System.Globalization.DateTimeFormatInfo_dtfi__DateTimeStyles_style.args:1337)
            at System.DateTime.ParseExact(System.String_s__System.String_format__IFormatProvider_provider.args:1337)
            at com.myapp.alpha.Parse.Internal.ParseDecoder.ParseDate(System.String_input.args:1337)
            at com.myapp.alpha.Parse.Internal.ParseObjectCoder.<Decode>b__3(System.Object_obj.args:1337)
            at com.myapp.alpha.eTime>>:invoke_TResult_T(object.args:1337)
            at com.myapp.alpha.Parse.Internal.ParseObjectCoder.extractFromDictionary[Nullable`1](IDictionary`2_data__System.String_key__System.Func`2_action.args:1337)
                        at com.myapp.alpha.Parse.Internal.ParseObjectCoder.Decode(IDictionary`2_data__Parse.Internal.ParseDecoder_decoder.args:1337)
            at com.myapp.alpha.Parse.Internal.ParseObjectController.<SaveAsync>b__2(System.Threading.Tasks.Task`1_t.args:1337)
            at com.myapp.alpha.Parse.Internal.InternalExtensions+<>c__DisplayClass1`2[System.Tuple`2[System.Net.HttpStatusCode,System.Collections.Generic.IDictionary`2[S\
ystem.String,System.Object]],Parse.Internal.IObjectState].<OnSuccess>b__0(System.Threading.Tasks.Task_t.args:1337)
            at com.myapp.alpha.Parse.Internal.InternalExtensions+<>c__DisplayClass7`1[Parse.Internal.IObjectState].<OnSuccess>b__6(System.Threading.Tasks.Task_t.args:133\
7)
                    at System.Threading.Tasks.ContinuationResultTaskFromTask`1[System.Threading.Tasks.Task`1[Parse.Internal.IObjectState]].InnerInvoke(.args:1337)
            at System.Threading.Tasks.Task.Execute(.args:1337)
            at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw(.args:1337)
            at com.myapp.alpha.Parse.Internal.InternalExtensions+<>c__DisplayClass7`1[System.Threading.Tasks.Task].<OnSuccess>b__6(System.Threading.Tasks.Task_t.args:133\
7)
                    at System.Threading.Tasks.ContinuationResultTaskFromTask`1[System.Threading.Tasks.Task`1[System.Threading.Tasks.Task]].InnerInvoke(.args:1337)
            at System.Threading.Tasks.Task.Execute(.args:1337)

And all we do with Parse (for now) is the following:

public override void OnCreate()
{
     base.OnCreate();

     RegisterActivityLifecycleCallbacks(new MyLifecycleHandler());

     ...

     var info = ParseHelper.GetInfo(BuildType);
     ParseClient.Initialize(info.AppId, info.NetKey);
     var installation = ParseInstallation.CurrentInstallation;
     installation.SaveAsync();
     ParsePush.ParsePushNotificationReceived += ParsePush.DefaultParsePushNotificationReceivedHandler;

}

We don't use anything else from Parse... Just the above. Speaking of which, I feel bit funny letting the Save.Async() call dangle like that, but don't really want to await it either. Anyhow, this doesn't always happen, but does happen sometimes. I think the fix would be to go through the code and try/catch around parsing date/time strings.

[richardjrossiii]

That seems odd. It would appear that the server is giving back Dates formatted improperly. I assume the answer is no, but are you using CloudCode anywhere? We've seen issues with CloudCode returning improper dates in the past (#38), but never from the main SDK.

We can definitely add better error handling code for cases where the server returns invalid data, but if it's consistently returning bad data, then it probably is a backend issue, which should be reported at http://parse.com/help.

[parse-github-bot]

Thank you for your feedback. We prioritize issues that have clear and concise repro steps. Please see our Bug Reporting Guidelines about what information should be added to this issue.

Please try the latest SDK. Our release notes have details about what issues were fixed in each release.

In addition, you might find the following resources helpful:

• Documentation: https://www.parse.com/docs
• Google Groups: https://groups.google.com/forum/#!forum/parse-developers
• Stack Overflow: http://stackoverflow.com/tags/parse.com

[habermeier]

@richardjrossiii No I don't use CloudCode anywhere. The only Parse SDK related call I make is in OnCreate() -- the bare minimum to get push notifications going.

I do not get this error a lot. I just saw it once or twice. But I did get it. Well -- really, someone in India got it. There could be 2 possibilities I can immagine: a) a transient bug on the server side, or b) a network related failure that isn't getting caught (or partially caught) and a null or empty string makes its way to the code that is trying to figure out the date. Pure speculation on my part of course.

All I know is what I have there...

[parse-github-bot]

This issue has not been updated for 7 days. If you have additional information to help pinpoint this issue as an SDK bug, please comment on this issue. We will close this issue in 7 days if no additional information is provided. Thank you for your feedback.

[habermeier]

@richardjrossiii do you still need more information from me on this? I think it's a bug in the SDK or possibly the server. The crash happened in India... is it possible there is a formatting issue around localized date representation?

[richardjrossiii]

@habermeier anything's possible. I'll check into locale, and mark this as under investigation for now. If I can't get it to fail, I'll have to mark it as 'needs more info again'.

[richardjrossiii]

After testing with my locale set to Indian, our dates are still parsing correctly, at least with all the examples I have tried.

To investigate this further I really need the string that's failing to parse, unfortunately.

[parse-github-bot]

Thank you for your feedback. We prioritize issues that have clear and concise repro steps. Please see our Bug Reporting Guidelines about what information should be added to this issue.

Please try the latest SDK. Our release notes have details about what issues were fixed in each release.

In addition, you might find the following resources helpful:

• Documentation: https://www.parse.com/docs
• Google Groups: https://groups.google.com/forum/#!forum/parse-developers
• Stack Overflow: http://stackoverflow.com/tags/parse.com

[habermeier]

@richardjrossiii I guess the only way to do that would be to add a try / catch block around

    internal static DateTime ParseDate(string input) {
      // TODO(hallucinogen): Figure out if we should be more flexible with the date formats
      // we accept.
      return DateTime.ParseExact(input,
          ParseClient.DateFormatString,
          CultureInfo.InvariantCulture);
    }

and log the problem there. But given this is likely coming from:

        if (typeString == "Date") {
          return ParseDate(dict["iso"] as string);
        }

That means dict["iso"] is either not set, or not set to something valid, which is unlikely to be a core issue with the SDK itself. Bottom line though is this: Why would it be OK to let the SDK crash if the server sent something bad to a client?

As an SDK user, I'd rather know that my app won't crash even if there is a temporary problem with the parse service. Bottom line, if you allow for there to be a possible problem with the server side, how would you protect my app from crashing? What should it do when it's expecting a date, but there is either no (or no valid date) coming from the server.

Crashing my app isn't the right answer. So I guess my point is: It kind of doesn't matter what the string was. What if I had logged it myself, and told you it was an empty string. Or a null pointer? Or a malformed date format.

Even if there was a bug upstream on the server side that could be fixed, there is no guarantee that in the future there won't be a bug introduced that screws this up.

The SDK should protect against crashing. Period.