Fix tests to avoid time zone dependent DateTime values#24323
Fix tests to avoid time zone dependent DateTime values#24323AlekseyTs merged 1 commit intodotnet:dev15.6.xfrom tlgkccampbell:master
Conversation
|
|
There was a problem hiding this comment.
DateTime.Parse(""2017-11-13T14:25:00Z"", CultureInfo.InvariantCulture, DateTimeStyles.AdjustToUniversal) [](start = 44, length = 104)
Can we simply use DateTime(Int64) constructor that takes the original number of tiks (636461511000000000)?
There was a problem hiding this comment.
I don't see why not. If that's preferable, I can update the PR.
There was a problem hiding this comment.
I don't see why not. If that's preferable, I can update the PR.
I think that would be preferable over making the unit-test dependent on Globalization APIs.
|
Done with review pass (iteration 1). |
|
Based on the console output, I'm a bit unclear on why the |
|
I've updated the PR to remove the dependency on the Globalization APIs, as requested. |
|
@tlgkccampbell Please re-target this PR against dev15.6.x branch. |
|
@AlekseyTs OK, I've re-targeted the PR. |
|
@tlgkccampbell Thanks for the contribution! |
Ask Mode template completed
Customer scenario
Unable to successfully run compiler tests in Eastern time zone
Bugs this fixes
N/A
Workarounds, if any
N/A
Risk
N/A
Performance impact
N/A
Is this a regression from a previous update?
No
Root cause analysis
The tests in question were introduced in 7063899. An instance of
DateTimeis used as an example of a reference type in the tests for this fix, but the way in which those instances are constructed is time zone dependent; theDateTime.Parse()method always converts the date toDateTimeKind.Local, meaning that the actual value ofTickswill be different depending on where in the world the tests are run.How was the bug found?
While in the Eastern time zone, I cloned Roslyn and tried to run the tests.
Test documentation updated?
N/A