---
title: nexyron.latest_global_temporal_event
url: https://nexyron.tech/docs/cypher/procedures/temporal-and-streaming/nexyron-latest-global-temporal-event
description: Return the latest contribution recorded in Nexyron's global temporal timeline.
---

# nexyron.latest_global_temporal_event

## Generic Description

Return the latest contribution recorded in Nexyron's global temporal timeline.

Simple example:

```cypher
CALL nexyron.latest_global_temporal_event()
YIELD ts
RETURN ts
```

`ts` is an `i64` epoch-millisecond timestamp. It is the latest available temporal data point in the database timeline, using an event's `end_ts` when the event is an interval and `start_ts` otherwise.

## Consumer-Level Explanation

Use `nexyron.latest_global_temporal_event()` when "now" should mean the newest timestamp present in the data rather than the machine's wall-clock time.

That distinction matters for analytical and ML workloads. A customer, device, member, patient, or operational dataset may have been exported months or years ago. A feature named `payments_last_30d` should usually mean "30 days before the dataset's latest event", not "30 days before the server clock at query time".

## Conceptual Explanation

The procedure reads the global temporal timeline high-water mark. The timeline receives contributions from temporal-property writes and other time-oriented stream/event surfaces that are recorded in Nexyron's temporal index.

Unlike `nexyron.global_time_range`, this procedure is not a timeline scan. The index maintains the latest event summary as data is recorded and rebuilds it only when the timeline is bulk-imported, pruned, or deleted. Normal reads are therefore constant-time relative to the number of timeline entries.

Use it as an anchor, then do the subject-specific work through `temporal_history`, `temporal_rollup`, or a scoped graph path:

```cypher
CALL nexyron.latest_global_temporal_event()
YIELD ts AS anchor_ts
MATCH (m:MemberAccount)
WHERE element_id(m) = 'n:1'
WITH element_id(m) AS subject_id, m, anchor_ts
CALL {
  WITH m, anchor_ts
  CALL nexyron.temporal_history(
    id(m),
    'member_payment_transactions_stream',
    anchor_ts - 2592000000,
    anchor_ts
  )
  YIELD ts
  RETURN count(*) AS payments_last_30d
}
RETURN subject_id, payments_last_30d AS value
```

## More Detailed Explanation

In practical queries, start by deciding the row grain you want after the call: one row per node, one row per path, one row per registry object, one row per artifact, or one row per summary. Then keep that grain explicit with `YIELD` and named projections. That is the difference between a useful planner-facing example and a vague call that downstream tooling cannot safely compose. For contract-driven procedures, the executable examples on these pages intentionally inspect procedure metadata unless the required named artifacts are created in the same example.

## Advanced Example

This feature computes an inactivity flag against the latest available data timestamp, not against wall-clock time:

```cypher
CALL nexyron.latest_global_temporal_event()
YIELD ts AS anchor_ts
MATCH (m:MemberAccount)
WHERE element_id(m) = 'n:1'
WITH element_id(m) AS subject_id, m, anchor_ts
CALL {
  WITH m
  CALL nexyron.temporal_history(
    id(m),
    'member_payment_transactions_stream',
    null,
    null
  )
  YIELD ts
  RETURN max(ts) AS latest_payment_ts
}
RETURN subject_id,
       latest_payment_ts IS NULL OR latest_payment_ts < anchor_ts - 2592000000 AS value
```

This shape avoids rescanning the full member population for every selected member. The only global operation is the cached high-water-mark lookup.

## Real Use Cases

-   Anchoring ML features such as "last 7 days", "last 30 days", inactivity, churn gap, freshness, recency, and rolling activity windows for historical exports.
-   Building reproducible feature snapshots where the reference time should come from the data itself.
-   Avoiding incorrect all-zero or stale recency features when the server clock is far beyond the dataset's last event.
-   Replacing broad `max(ts)` discovery scans that were only trying to find the dataset's latest temporal timestamp.

## Real Limitations And Tradeoffs

-   The procedure returns the latest event in the global temporal timeline, not the latest event for one specific label, subject, or property. For property-specific latest values, use it only as the global anchor and still compute the subject/property-specific value through the proper scoped temporal history or rollup.
-   It returns no rows when the global temporal timeline is empty. Feature contracts should handle that case only when the dataset may genuinely have no temporal data.
-   The high-water mark is maintained by timeline-aware writes. Plain scalar properties that were never registered as temporal properties do not contribute to this procedure.
-   It should not replace `global_time_range` when the caller actually needs ranked subjects or timeline activity across a range.