Roslyn analyzers for bug-prone usage of DateTime/DateTimeOffset

[timmydo]

I recently ran into two separate bugs related to time handling in our code and thought roslyn analyzers might be able to assist.

The two instances were:

DateTimeOffset.Parse("2020-01-02").ToString(...)
and
if (DateTimeOffset.TryParse(expiryString, out var expiry) && now < expiry) // expiry is a utc YYYY-MM-DD date

in both of these usages, I should have used something like DateTimeOffset.TryParse(expiryString, null, System.Globalization.DateTimeStyles.AssumeUniversal, out var expiry)

I see this as similar to requiring explicit usage of culture objects in string comparisons. Is there an analyzer that could recommend the version of the function with the explicit default behavior request like we have for string comparison functions?

Semi-related #43956

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[Clockwork-Muse]

I see this as similar to requiring explicit usage of culture objects in string comparisons.

Yes, especially for one surprising reason - at least one culture uses a YYYY-DD-MM format.

in both of these usages, I should have used something like

You should be using

DateTimeOffset.TryParse(expiryString, DateTimeFormatInfo.InvariantInfo, out var expiry)

... which is explicitly using a culture.

[timmydo]

Well, I'm glad my attempt at a fix is wrong if it makes the case for an analyzer stronger :)

[tarekgh]

Actually, if you previously know the format of the date string you should use [Try]ParseExact instead of [Try]Parse.

[Try]Parse is useful only if having date strings which you don't know the actual format and try to parse to get something from it. Recommending Invariant culture or anything else here can break other user cases. We need to think more how we can write this analyzer to address the bad usages and allow the legitimate usage in same time.

[timmydo]

I don't think you should recommend invariant culture--you just need to recommend using an API where the culture is explicitly specified, similar to how string comparison API analyzers recommend you specify the culture explicitly.