Summary
comparison={ compare_vs="prior period" } works when the period is set by an explicit date_range, but reports a flat 0.00% when the same period comes from a range_calendar filter via filters=[...]. The value itself is correct in both cases — only the comparison is wrong, and it fails silently rather than erroring or omitting the delta.
Environment
- Evidence CLI v0.9.3 (latest)
- BigQuery direct connector
Steps to reproduce
{% range_calendar id="dates" value_column="start_date" default_range="last 7 days" /%}
<!-- A: period from the filter -->
{% big_value data="v" value="sum(amount)" fmt="usd2"
filters=["dates"]
comparison={ compare_vs="prior period" delta=true } /%}
<!-- B: period from date_range -->
{% big_value data="v" value="sum(amount)" fmt="usd2"
date_range={ range="last 7 days" date="start_date" }
comparison={ compare_vs="prior period" delta=true } /%}
Actual
Both render the same value ($6,573.38), confirming the filter applies correctly, but:
- A →
▲ 0.00% vs. last period
- B →
▲ 4.04% vs. last period
B is correct.
Expected
A should resolve the prior period from the filter's active range and report 4.04% as well. Failing that, it should omit the comparison rather than render a confident, wrong 0.00%.
Impact
Medium-high. This is the natural way to build a dashboard — one date picker driving every tile — and it silently reports "no change" on every KPI. A reader has no way to tell the delta is broken. In a dashboard with a shared date filter, comparison is effectively unusable, and its failure is indistinguishable from genuinely flat metrics.
Summary
comparison={ compare_vs="prior period" }works when the period is set by an explicitdate_range, but reports a flat0.00%when the same period comes from arange_calendarfilter viafilters=[...]. The value itself is correct in both cases — only the comparison is wrong, and it fails silently rather than erroring or omitting the delta.Environment
Steps to reproduce
{% range_calendar id="dates" value_column="start_date" default_range="last 7 days" /%} <!-- A: period from the filter --> {% big_value data="v" value="sum(amount)" fmt="usd2" filters=["dates"] comparison={ compare_vs="prior period" delta=true } /%} <!-- B: period from date_range --> {% big_value data="v" value="sum(amount)" fmt="usd2" date_range={ range="last 7 days" date="start_date" } comparison={ compare_vs="prior period" delta=true } /%}Actual
Both render the same value (
$6,573.38), confirming the filter applies correctly, but:▲ 0.00% vs. last period▲ 4.04% vs. last periodB is correct.
Expected
A should resolve the prior period from the filter's active range and report 4.04% as well. Failing that, it should omit the comparison rather than render a confident, wrong
0.00%.Impact
Medium-high. This is the natural way to build a dashboard — one date picker driving every tile — and it silently reports "no change" on every KPI. A reader has no way to tell the delta is broken. In a dashboard with a shared date filter,
comparisonis effectively unusable, and its failure is indistinguishable from genuinely flat metrics.