[jira] [Closed] (TINKERPOP-3276) gremlin-javascript offsetdatetime silently creates incorrect values

["Yang Xia (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TINKERPOP-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yang Xia closed TINKERPOP-3276.
-------------------------------
    Fix Version/s: 3.8.2
       Resolution: Fixed

> 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
>            Assignee: Yang Xia
>            Priority: Minor
>             Fix For: 3.8.2
>
>
> 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)