#245 · Read zoomed-in offsets in a smaller unit when a display counts in a large one
- timeline-app
- pull request
Fixes #242. Zoomed far into a display that counts in a large unit (the deep-time sample's millions of years), the ruler switched to offset (Δ) labels such as "Δ 1.446e-13 million…". Their caption was a fraction of enormous integers: "Δ from -1522403…/5000000000000000000000 million years". **Now**, when the display's scale is one of the unit menu's presets and the view is shorter than one of its units: - Offsets count in the largest smaller preset the view spans. Under a minute they count in seconds with SI prefixes, so labels read "Δ 7 s", "Δ 250 ms", "Δ 2 hours" or "Δ 3 days", singular at one ("Δ 1 hour"). - They count from a round base, a power of ten of that unit past the origin, and the ruler plans its ticks in that unit. Labels fall on whole numbers and stay put while panning within a step; before, they counted from the moving left edge. - They parse back exactly, so typed and reapplied labels still choose the same time. - The caption gives the base as a decimal with just the digits the view resolves, marked "≈" when it isn't exact. **Unchanged:** displays already in a small unit, and views longer than one unit. A story counted in years still reads "Δ 3 AR" at a ten-year view. So are SI displays and custom code. **Tests:** - A new test covers the deep-time display at 8-second, quarter-second, 3-hour and 40-day views: every labelled tick prints a round offset in the expected unit and parses back to its exact time, and the caption is short. - It also checks that a years display at a ten-year view keeps its own unit. - `npm test` passes (302), and so does the Chromium browser suite. - I checked both views in the real editor on the deep-time sample. [Time presentation](docs/time-presentation.md) describes the new behaviour.