Fix invalid datetimeoffset parsing #87801
Conversation
ghost
added
the
community-contribution
|
Tagging subscribers to this area: @dotnet/area-system-datetime Issue DetailsCurrent PR fix #51740
|
Maximys
force-pushed
the
bugfix/51740-invalid-datetimeoffset-parsing
branch
from
e01f31c
to
dedd936
Compare
danmoseley
changed the title
| { | ||
| DateTimeOffset expected = DateTimeOffset.MaxValue; | ||
| string expectedString = expected.ToString(); | ||
| yield return new object[] { "2021-04-23T13:04:17,307642270+02:00", new DateTimeOffset(637547798573076423, new TimeSpan(2, 0, 0)) }; |
There was a problem hiding this comment.
@ericstj (or somebody else from area-System.DateTime), pay attention on this line, please. I think, expected value should be represented by DateTimeOffset(Int32, Int32, Int32, Int32, Int32, Int32, Int32, TimeSpan), but max value of millisecond is 999, that's why I could not use this constructor
There was a problem hiding this comment.
You can do something like:
{ "2021-04-23T13:04:17,307642000+02:00", new DateTimeOffset(2021, 4, 23, 13, 4, 17, 307, 642, TimeSpan.FromHours(2)) }There was a problem hiding this comment.
@tarekgh , thanks, but next code result is false:
DateTimeOffset dt = new DateTimeOffset(2021, 4, 23, 13, 4, 17, 307, 642, TimeSpan.FromHours(2));
DateTimeOffset dt2 = DateTimeOffset.Parse("2021-04-23T13:04:17.307642270+02:00");
Console.WriteLine(dt == dt2);
because dt.Ticks is 637547798573076420 and dt2.Ticks is 637547798573076423 (last digit is different), that's why I had post my previous comment
There was a problem hiding this comment.
Note I used "2021-04-23T13:04:17,307642000+02:00" and not "2021-04-23T13:04:17.307642270+02:00".
There was a problem hiding this comment.
@tarekgh , yes, you are right, with 6 significant digits (I mean "307642" without "270") test will be successful, but inside bug we have "2021-04-23T13:04:17,307642270+02:00". As you can see, count of significant digits of "2021-04-23T13:04:17,307642270+02:00" is 8 ("30764227"), which add 3 to last digit of Ticks ("0.xxxx227" rounded to "0.xxxx3") and I think, that we should not use good data to test case just for pass it.
If you want to know my opinion, I think we should change type of "microsecond" argument from Int32 to float and apply range 0<=microsecond<1000. Then we can pass 642.3 to it and my test will be pass.
There was a problem hiding this comment.
new DateTimeOffset(2021, 4, 23, 13, 4, 17, TimeSpan.FromHours(2)).AddTicks(3076423) would have been another option, easier to visually verify as equivalent to 2021-04-23T13:04:17,307642300+02:00. Not worth changing now, though.
Current PR fix #51740