gentle phoenix
I noticed that [this bug](#rate-app message) has never been mentioned or addressed since I reported it, and on the latest version it still exists.
It really is as simple as changing DateTime.UtcNow to DateTime.Now though I'm unsure why m_stateInfo.PromptLastShown loads the Utc DateTime from the .json storage into a localized DateTime on startup.
plush palm
@gentle phoenix The issue you raised was valid. Unfortunately, we couldn't finish fixing it in our last release. We wanted to make sure the change is unaffected for timezone changes. Using local time for difference will break once the user changes the timezone. Can you please check if the following fixes it by considering UTC?
plush palm
private static DateTime? DeserializeDateTime(string dateTimeStr)
{
DateTime dateTime;
if (DateTime.TryParse(dateTimeStr, CultureInfo.InvariantCulture,DateTimeStyles.AdjustToUniversal, out dateTime))
{
return dateTime;
}
return null;
}
You need to still keep the code as UtcNow with the above change.
gentle phoenix
What's funny is I was actually just looking into making that change right now, I literally have https://learn.microsoft.com/en-us/dotnet/api/system.datetime.tryparse?view=netframework-4.8#remarks open in another tab 😂
I'll use that code and report back if it fixes the issue for me.
plush palm
DateTime is a bit complexly designed when it comes to conversions. When it converts to string, it should convert back to the same DateTimeKind which is usual expectation.
gentle phoenix
Yeah, from my reading DateTime.TryParse will always try to convert to LocalTime by default, since DateTime itself doesn't store information on it's timezone or UTC offsets. (At least according to Soner on StackOverflow.)
plush palm
Agreed. However, it's our mistake, if I need to make it explicit 😄
I always miss the part that datetime parses back to local.
I wish it saves the datetimekind when it saves so that it can construct back easily.
Anyways, sorry for not considering the fix. We couldn't accommodate it.
gentle phoenix
I always miss the part that datetime parses back to local.
It's an understandable mistake to make, I would've assumed that the DateTimeKind was also serialized and deserialized myself.
I was able to test and confirm that with your change it does properly load the PromptLastShown time as UTC.
Thank you!