Ken Hu created TINKERPOP-3276:
---------------------------------
Summary: 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
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)
