So we've run into a really weird crash using Xamarin Android with the C# client sdk. We hit it before with some of our own code and handle the issue there, but now we're seeing the crash inside the Playfab SDK json parsing code. It stems from how DateTime string parsing is handled for different "CultureInfo" or languages.
Basically the SDK, when parsing the DateTime needs to pass in which Culture to use, and is currently passing in "CultureInfo.CurrentCulture" which means it looks up the current device to know how to interpret the string representing the DateTime. On Android this causes a system call to find the current language, get the Calendar associated with that language, find out how they format their dates so it knows how to parse it.
Current Issue: On languages that have different calendars, that calendar might not be installed thus causing a hard crash. This is the source of the crash we're seeing in some languages (specifically Arabic).
Design Issue: Even if we worked around the calendar issue, it still seems weird that the SDK is hardcoding the CurrentCulture usage. The crash we're seeing hits as soon as we do any login, because part of the return value contains "Last login time". From my experience with similar issues the usual practice is to write libraries to use the "Invariant" culture (especially when dealing with backend) and leaving all "convert to local culture/timezone" to the client/user facing code. If we DID get past the calendar crash, I'm not even sure it'd still work because (I'm assuming at this point) we'd hit a crash trying to interpret a DateTime from the server in what (I'm assuming) is UTC format as a DateTime string in whatever culture setting the user has locally on their device.
(As a reference point while searching for existing posts about this in this forum I found this 3 year old post about the C++ SDK doing the same thing, where even though the server stored times in UTC by the time the SDK client call finished parsing it, it's no longer stored as UTC and instead in the users local timezone settings. Although they weren't dealing with a crash like us, they seemed to have the similar expectation that the api calls should be returning the values as invariant: https://community.playfab.com/questions/17262/playfab-c-client-sdk-timestamps-are-in-local-time.html)
Solution: What we did when we hit this with our own DateTime parsing is on the parse calls change from CultureInfo.CurrentCulture to CultureInfo.InvariantCulture. This causes it to use a standardized format independent of language/culture settings. At that point we can leave it to the UI to convert it to the users local culture. I've found the few lines in the Playfab Client SDK repo where this change would be needed, and even have a PR that I could request to put in, but I don't even know if Playfab allows external PRs, especially since I couldn't find the issues tab to even file the issue.
My main question is if this is something that would be considered for a fix, and if so if the repo is open to a PR to fix it, because if not we're going to need to fork the repo and start building it on our own which is its own pain.