[
https://issues.apache.org/jira/browse/TINKERPOP-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Hu updated TINKERPOP-3276:
------------------------------
Description:
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
was:
Caveat: I haven't fully verified this, just something AI told me when I was
writing the "model" tests for gremlin-go. 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
> 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)
