Add start_time and end_time coords for accurate time display in plot titles #652
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Job.get() now adds start_time and end_time as 0-D coordinates (unit: ns) to all DataArrays in the result DataGroup. These coordinates provide temporal provenance for each output, enabling lag calculation in the dashboard (lag = current_time - end_time). Addresses issue #444 and provides foundation for #634. Prompt: We need to think about how we can address #444 and also take into account #634.
Display data lag (current_time - end_time) in HoloViews plot titles. The lag shows how old the displayed data is, updating each time the plot refreshes with new data. This is a first implementation to evaluate the UX. The lag appears as "Lag: X.Xs" in the plot title when the data has an end_time coordinate. Addresses issue #634.
Delta outputs like 'current', 'roi_spectra_current', and counts now have their own start_time and end_time coords representing the period since the last finalize, not the entire job duration. This fixes misleading time display in the dashboard for these outputs. Changes: - _add_time_coords() now skips DataArrays with existing time coords - DetectorView tracks _current_end_time alongside _current_start_time - All delta outputs get start_time/end_time coords set by the workflow Prompt: This branch add a time info display by adding and using start_time and end_time. This works. However, there are workflows such as the detector views that produce a cumulative and current output... but the start_time is set to the same for both, misleading the user as to what period was used to obtain the "current" (delta since last update) counts. Please think about how to solve this. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The time interval display in plot titles now shows tenths of seconds (e.g., "12:34:56.7" instead of "12:34:56") for better precision when monitoring fast-updating data. Prompt: Consider this branch, in plots.py we should display timestamps to 0.1s precision Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Apply the same pattern as DetectorView: delta outputs (current, counts_total, counts_in_toa_range) now have start_time and end_time coords representing the period since the last finalize. Cumulative outputs do not get these coords, allowing Job.get() to add job-level times. Prompt: implement for monitors and commit
The comment suggested 'time' was only kept for backwards compatibility, but it's an important coord used for timeseries plotting. Also includes import ordering fixes from ruff.
…t titles Previously, TemporalBuffer stored start_time/end_time only from the first item in a "reference", causing plot titles to show stale time information that didn't reflect the actual data range being displayed. Now TemporalBuffer accumulates start_time/end_time as 1-D coordinates (one value per time slice), similar to how it handles the time coordinate. Extractors compute min/max of these 1-D coords to get accurate scalar bounds for plot titles. Changes: - TemporalBuffer: Add dedicated buffers for start_time and end_time coords - FullHistoryExtractor: Compute min/max of 1-D time coords - WindowAggregatingExtractor: Capture time bounds from windowed data before aggregation removes the time dimension Prompt: Please consider changes in this branch. We need to understand how we handle time-interval display in the plot titles (added in plots.py) in the case of (a) timeseries plots (extracting full history) and (b) regular plots with a configured 'window'. In both cases we need to ensure that the time info is factual. After you understood the problem, I'd like to implement tests that check for the behavior we desire; if they fail we can think about how to solve this. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
FullHistoryExtractor and WindowAggregatingExtractor had duplicate logic for extracting scalar time bounds from 1-D coords. Replaced with a single _extract_time_bounds_as_scalars helper that both extractors now use. Prompt: Consider changes in this branch in extractor.py - why is the implementation different for the window extractor? Can we use the same helper somehow? Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR fixes #444 and fixes #634 by adding temporal provenance to job outputs and displaying time information in plot titles.
Key changes:
Job.get()now addsstart_timeandend_timeas 0-D coordinates (in ns) to allDataArrayoutputs, enabling the dashboard to show when data was collected and compute lagTemporalBufferaccumulatesstart_time/end_timeas 1-D coordinates per time slice, allowing extractors to compute accurate bounds for windowed viewsNote: This is an initial implementation to evaluate the UX. We expect further changes based on feedback, for example:
Example
Test plan
Job.get()time coord injection, extractor time handling, andTemporalBufferaccumulation🤖 Generated with Claude Code