[Bug]: Datetime picker sets to 26/04/98 when entering from: manually and to: set to now #1151

Activity

1. Yarrith

   added

   bugSomething isn't workingSomething isn't working

   needs triage

   on Aug 21, 2026
2. Yarrith commented on Aug 30, 2026

   

   Yarrith

   on Aug 30, 2026

   Last edited by Yarrith

   Author

   More actions

   Reproduced and tried to reverse-engineer what is happening (dashboard v7.116.0, also affects the self-hosted Agent dashboard at :19999, e.g. Netdata v2.11.0).

   Repro is specific to typing a "From" value while "To" is left on "now" (picking From from the calendar is a different code path).

   Tested it on a local agent. Two runs:

   typed "From" (UTC)	after Apply	URL after / before
   2026-01-15 12:30	1998-01-08, 1-minute range	884240070000 / 884240130000
   2026-02-28 22:00	1998-01-30, 1-minute range	886157970000 / 886158030000

   In both cases the applied midpoint (after + before) / 2 equals exactly enteredFrom_ms / 2. So:

   1. "To = now" is held as the sentinel before = 0 and is never resolved to the real current time on the Apply path.
   2. Apply computes (after + before) / 2; with before = 0 this halves the entered "From" timestamp, landing ~28 years in the past (~2026 / 2 ≈ 1998). My previous 26/04/98 is a "From" near the 21 Aug 2026 filing date, halved.
   3. after now equals before, so the ~60 000 ms minimum-duration clamp expands it into the 1-minute window seen above — which also silently drops "follows now".

   The picker holds "To = now" as 0 (displayValue: 0 === endDate ? "now" : undefined). setValidEndDate normalizes that sentinel and converts a relative start to absolute; setValidStartDate has no equivalent, and nothing on the Apply path substitutes real now for the 0 before the averaging step.

   This is a best guess based on reverse-engineering the minified picker bundle, not the actual source — the observed behaviour is solid, the exact internal call path is inferred.