Read the JSON of a Newtonsoft contract test the way a response is read, and say what a date-like string is

[danielcweber]

The Newtonsoft contract tests now read their JSON the way a server response is read, with DateParseHandling.None, so that a string that looks like a date reaches Gremlinq's converters as the string it is. Until now they used JToken.Parse, which turns such a string into a date before any converter has seen it, in the machine's time zone - a path no response takes, and one on which both deserializers could not be held to the same answer. With that gone, the contract says what a date-like string is read as: a date where a date is asked for, and the string it came as everywhere else.

Changes

• Support.NewtonsoftJson.Tests: GraphsonSupportTest.CreateNativeToken mirrors DeferToNewtonsoftConverterFactory: UTF-8 bytes through a StreamReader and a JsonTextReader with DateParseHandling.None, everything else on the reader as it is created (FloatParseHandling.Double, a MaxDepth of 64, the invariant culture), and the token built by a default JsonSerializer rather than by JToken.Load. The last part is mirrored too, because it is not the same: a name that occurs twice is kept at its last place rather than its first, a comment is kept as a token, and text after the token is not an error.
• Support.NewtonsoftJson.Tests: four tests in TransformerTest hand the deserializer a JValue that holds a DateTime or a DateTimeOffset. No token of a response holds a date, so with the contract tests reading as a response is read, the arms of DateTimeConverterFactory and DateTimeOffsetConverterFactory that take such a token were reached by nothing - yet a token a caller read or built on its own may hold one. The date it holds is the date that is read, as it is held: a DateTime keeps its kind, a DateTimeOffset its offset.
• Tests.Infrastructure: fifteen contract tests after DateTimeOffset_from_invalid_string, each answered alike by Newtonsoft and System.Text.Json:
  • a string naming an offset, as a DateTimeOffset and as a DateTime: the instant it names, in UTC. A fraction of a second is kept down to the tick. DateTimeOffset_from_double is the counterpart DateTime_from_double did not have.
  • a string naming no offset, "2020-01-02", as a DateTime and as a DateTimeOffset: the local midnight of the machine reading it. The instant differs from machine to machine, so these two hold that it is that local midnight rather than the instant.
  • a date-like string as a string and as an object - naming UTC, naming an offset, a date alone, in an array read as object[] and as a value of a g:Map: the string it came as.
  • a date-like string as a property of an entity: Person.RegistrationDate reads it as the date, Person.Name keeps it as the string, and a RegistrationDate that is no date costs the property, not the person.

Notes

• Tests only; nothing in src/ changes, hence skip-changelog.
• No existing snapshot changed with the way of reading: the three date-like strings the contract had all name UTC and are all asked for as dates. Measured in Europe/Berlin for what it had not: "2020-01-02T03:04:05+02:00" as a DateTimeOffset was 02:04:05 +01:00 with JToken.Parse and is 01:04:05 +00:00 as a response is read; as an object it was a DateTime and is the string; as a string it was 01/02/2020 02:04:05 and is the string as it came.
• The Newtonsoft tests went from 299 to 318 and pass in Europe/Berlin, America/New_York and Asia/Kolkata alike. The System.Text.Json contract tests in Gremlinq.Extensions verify against the same snapshots and pass with them unchanged, in the same three time zones.
• Coverage: the first run of this pull request had codecov/project fail at 93.55% (-0.04%), three lines in the two date converters named above and nowhere else. The four TransformerTest tests are the answer to that; the arm of DateTimeOffsetConverterFactory for a token holding a DateTimeOffset had been covered by nothing before either.
• The other tests of Support.NewtonsoftJson.Tests that parse with JObject.Parse (TransformerTest, JTokenHeuristicTests, DynamicDictionaryTests) are left as they are: none of their literals has a date-like string, a repeated name or a comment, so both ways of reading give them the same token. Issue219 already goes through the reader a response goes through.
• Left out, because the two implementations do not answer alike, and reported rather than changed here: the offset of a DateTimeOffset read from a string naming none (UTC on Newtonsoft, the machine's own on System.Text.Json, the instant being the same), "/Date(1577934245000)/" (a date on Newtonsoft through its own fallback, declined by System.Text.Json), and dates at the very ends of the range.
• The Gremlinq.Extensions forward rides along with the next pull request there and needs no change of its own.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.67%. Comparing base (14da617) to head (7e82345).

Additional details and impacted files

@@            Coverage Diff             @@
##             14.x    #2478      +/-   ##
==========================================
+ Coverage   93.64%   93.67%   +0.02%     
==========================================
  Files         279      279              
  Lines        7903     7903              
  Branches      885      885              
==========================================
+ Hits         7401     7403       +2     
+ Misses        311      310       -1     
+ Partials      191      190       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.