Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make ParseDateTimeTimeZoneSafe culture aware #58

Merged
merged 7 commits into from
Feb 23, 2017
Merged

Make ParseDateTimeTimeZoneSafe culture aware #58

merged 7 commits into from
Feb 23, 2017

Conversation

axunonb
Copy link
Collaborator

@axunonb axunonb commented Feb 20, 2017

Fixes issue https://github.com/sinairv/YAXLib/issues/35
As @gitgordon pointed out, the public static method ParseDateTimeTimeZoneSafe does not use the argument IFormatProvider, and so the culture which DateTimeOffset.TryParse is expected to use is not set by YAXLib code. Depending on the system culture or the culture set by any code for the current thread it might work or fail.
With NUnit3 tests the current culture was set System.Globalization.CultureInfo.InvariantCulture which was the reason for the tests to succeed.
This fix seems to be kind of urgent IMHO.

Fixes issue https://github.com/sinairv/YAXLib/issues/35
As @gitgordon pointed out, the public static method ParseDateTimeTimeZoneSafe does not use the argument IFormatProvider, and therefore the culture which DateTimeOffset.TryParse is expected to use is not set by YAXLib code. So depending on the culture previously set (e.g. system default culture) it might work or fail.
@codecov-io
Copy link

codecov-io commented Feb 20, 2017

Codecov Report

❗ No coverage uploaded for pull request base (master@679d071). Click here to learn what that means.
The diff coverage is 0%.

@@            Coverage Diff            @@
##             master      #58   +/-   ##
=========================================
  Coverage          ?   69.37%           
=========================================
  Files             ?       13           
  Lines             ?     2622           
  Branches          ?      634           
=========================================
  Hits              ?     1819           
  Misses            ?      621           
  Partials          ?      182
Impacted Files Coverage Δ
YAXLib/StringUtils.cs 95.16% <ø> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 679d071...8b6e225. Read the comment docs.

@304NotModified
Copy link
Collaborator

304NotModified commented Feb 20, 2017

👍

@304NotModified
Copy link
Collaborator

304NotModified commented Feb 20, 2017

Would be great if you add an unit test :)

@axunonb
Copy link
Collaborator Author

axunonb commented Feb 20, 2017

Hm, you mean mimic the bug? Doesn't really make sense I'm afraid :)
The CultureChangeTest() is already there and it's fine. Now it will always work.

@304NotModified
Copy link
Collaborator

Can't agree on this.

This could be a serious bug for a lot of non-english users. That the unit test was passing already, shows only that it isn't a good test.

@304NotModified
Copy link
Collaborator

@axunonb
Copy link
Collaborator Author

axunonb commented Feb 21, 2017

Looks like I'm outvoted :)
So: The serialization test for the CultureSample was okay. I double-checked the tests and found that there was no corresponding deserialization test which would have failed because of the bug. So I added what was missing. Agree?

@304NotModified
Copy link
Collaborator

Great!


Assert.That(expected, Is.EqualTo(usResult), "Checking US is as expected!");
// deserialization results
Assert.AreEqual(0, faDesResult?.CompareTo(frDesResult), "Comparing deserialized FA and FR");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not Assert.AreEqual(faDesResult,frDesResult) ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strange enough, but this fails...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

both are strings right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, a CultureSample instance.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's why I introduced the IComparable to CultureSample.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah then I would be better to generate equals(). Resharper can do that for you :)

@304NotModified
Copy link
Collaborator

With NUnit3 tests the current culture was set System.Globalization.CultureInfo.InvariantCulture which was the reason for the tests to succeed.

After this comment I was excepting to test it just with other current cultures?

e.g.

  • set currentCulture = "fr-fr"
  • test
  • set currentCulture = "en-gb"
  • test
  • etc

Which could be done with Unit test parameters

@sinairv sinairv merged commit cb1c1d2 into YAXLib:master Feb 23, 2017
@sinairv
Copy link
Collaborator

sinairv commented Feb 23, 2017

Thanks for the fix. Great work.

@304NotModified
Copy link
Collaborator

yes great work @axunonb ! 🥂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants