[
https://issues.apache.org/jira/browse/TINKERPOP-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18099535#comment-18099535
]
ASF GitHub Bot commented on TINKERPOP-3276:
-------------------------------------------
xiazcy merged PR #3549:
URL: https://github.com/apache/tinkerpop/pull/3549
> gremlin-javascript offsetdatetime silently creates incorrect values
> -------------------------------------------------------------------
>
> Key: TINKERPOP-3276
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3276
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
> Affects Versions: 3.8.1
> Reporter: Ken Hu
> Priority: Minor
>
> Caveat: I haven't fully verified this, just something AI told me when I was
> updating the "model" tests for gremlin-javascript. Just putting here so it
> can be checked later.
> JavaScript Date has a much smaller valid range than Gremlin/JVM date-time
> types. GraphBinary can encode extreme values like OffsetDateTime.MAX,
> OffsetDateTime.MIN, or the GraphBinary v4 DateTime equivalents with years
> around +999999999 / -999999999.
> The JavaScript GraphBinary reader currently reads the wire fields
> successfully:
> year, month, day, nanoseconds-since-midnight, utc-offset
> Then it tries to convert them into a native JS Date:
> new Date(Date.UTC(year, month, day, hour, minute, second, millisecond))
> For those extreme years, Date.UTC(...) returns NaN because the value is
> outside the supported JS Date range. new Date(NaN) does not throw. It creates
> an
> invalid Date object. So deserialization appears to succeed, but the returned
> object is unusable:
> value instanceof Date // true
> Number.isNaN(value.getTime()) // true
> value.toISOString() // throws RangeError
> What should happen instead:
> The reader should detect that the decoded date-time cannot be represented as
> a valid JavaScript Date and fail deserialization with a clear error. For
> example, after constructing the Date, it should validate:
> if (Number.isNaN(v.getTime())) {
> throw new Error('DateTime value is outside the supported JavaScript Date
> range');
> }
> The important behavior change is: unsupported date-time boundary values
> should not silently become invalid Date instances. They should be rejected
> during
> deserialization, just like other unsupported GraphBinary values
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
