xiazcy opened a new pull request, #3549: URL: https://github.com/apache/tinkerpop/pull/3549
### 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`: ```js 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 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
