datetime(map) ignores epochSeconds and epochMillis, returning an unrelated default date #5274

ArcadeDB version

ArcadeDB 26.8.1-SNAPSHOT

Verified on July 14, 2026, in a fresh container created from:

arcadedata/arcadedb:latest

Environment

• Host OS: Linux 5.4.0-216-generic
• Deployment: Docker
• Query interface: HTTP API
• Query language: Cypher

Description

The datetime(map) constructor silently ignores the epochSeconds and epochMillis fields.

The query succeeds, but the returned datetime is unrelated to the supplied epoch value. In the tested environment, all such calls returned:

2026-01-01T00:00Z

The issue appears limited to the map-constructor path. The dedicated datetime.fromepoch() and datetime.fromepochmillis() functions return the correct values on the same ArcadeDB version.

If epochSeconds and epochMillis are not supported in datetime(map), ArcadeDB should reject these fields explicitly rather than accepting the map and returning an unrelated datetime.

Compatibility basis

The Cypher temporal-function documentation lists epochSeconds and epochMillis as valid datetime(map) components:

https://neo4j.com/docs/cypher-manual/current/functions/temporal/

ArcadeDB documents its Cypher implementation and compatibility scope here:

https://docs.arcadedb.com/arcadedb/reference/cypher/cypher-compatibility

Steps to reproduce

No graph data is required.

RETURN
  datetime({epochSeconds: 0}) AS mapSeconds,
  datetime({epochMillis: 1000}) AS mapMillis,
  datetime.fromepoch(0, 0) AS functionSeconds,
  datetime.fromepochmillis(1000) AS functionMillis;

Actual behavior

mapSeconds      = 2026-01-01T00:00Z
mapMillis       = 2026-01-01T00:00Z
functionSeconds = 1970-01-01T00:00Z
functionMillis  = 1970-01-01T00:00:01Z

Changing the epoch values does not change the map-constructor result:

RETURN
  datetime({epochSeconds: -1}) AS negativeSeconds,
  datetime({epochSeconds: 1000000000}) AS positiveSeconds,
  datetime({epochMillis: 1}) AS oneMillisecond;

Actual result:

negativeSeconds = 2026-01-01T00:00Z
positiveSeconds = 2026-01-01T00:00Z
oneMillisecond  = 2026-01-01T00:00Z

Expected behavior

For compatibility with the documented Cypher datetime(map) components:

datetime({epochSeconds: 0})   = 1970-01-01T00:00Z
datetime({epochMillis: 1000}) = 1970-01-01T00:00:01Z

If these map fields are intentionally unsupported, ArcadeDB should return a clear error identifying the unsupported fields.

It should not return a successful but unrelated datetime value.

Control queries

The dedicated epoch functions work correctly:

RETURN datetime.fromepoch(0, 0) AS result;

Result:

1970-01-01T00:00Z

RETURN datetime.fromepochmillis(1000) AS result;

Result:

1970-01-01T00:00:01Z

The calendar-map constructor also works correctly:

RETURN datetime({
  year: 2001,
  month: 9,
  day: 9
}) AS result;

Result:

2001-09-09T00:00Z

Additional diagnostic

Maps without recognized temporal components show the same fallback behavior:

RETURN
  datetime({}) AS emptyMap,
  datetime({foo: 123}) AS unknownField;

Actual result:

emptyMap     = 2026-01-01T00:00Z
unknownField = 2026-01-01T00:00Z

This suggests that unrecognized fields are ignored and the remaining empty map is converted into a default calendar value.

The primary issue concerns epochSeconds and epochMillis because they are documented Cypher datetime components.

Cross-engine diagnostic comparison

The expected behavior is based on the documented Cypher datetime components, not solely on cross-engine agreement.

Reproducibility

The complete test matrix was executed three times in a fresh Docker container.

All three runs returned identical results.

Impact

Applications using the epoch map form receive a successful response containing a datetime unrelated to the supplied input.

If the returned value is persisted or used in subsequent computations, this can cause silent temporal data corruption rather than a visible compatibility error.

Workaround

Use the dedicated epoch conversion functions:

datetime.fromepoch(seconds, nanoseconds)
datetime.fromepochmillis(milliseconds)