[TINKERPOP-3276][gremlin-javascript] Reject out-of-range OffsetDateTime values

[xiazcy]

Summary

The gremlin-javascript OffsetDateTime deserializers constructed a native Date without validating the result. JavaScript's Date has a much narrower range than Gremlin/JVM date-time types, so extreme boundary values (e.g. years near ±999999999, or OffsetDateTime.MAX/MIN) produced NaN. Because new Date(NaN) does not throw, deserialization appeared to succeed but returned an unusable Date:

value instanceof Date          // true
Number.isNaN(value.getTime())  // true
value.toISOString()            // throws RangeError

Both readers now detect that condition and fail deserialization with a clear error, so unsupported boundary values are rejected up front rather than silently becoming invalid Date instances — consistent with how other unsupported values are handled.

Changes

• GraphBinary (internals/OffsetDateTimeSerializer.js): after building the Date from the wire fields, throw if Number.isNaN(v.getTime()).
• GraphSON (type-serializers.js): the same guard in OffsetDateTimeSerializer.deserialize, for parity.
• Added OffsetDateTimeSerializer-test.js (GraphBinary) covering normal round-trips and boundary rejection for ±999999999.
• Added GraphSON reader tests: a normal gx:OffsetDateTime round-trip and boundary rejection for expanded-year ISO strings.

---

VOTE +1

[Cole-Greer]

VOTE +1