Monthly totals from a re-spaced daily series show February well below January — is that a real decline?

## A calendar step is a rule, not a length When a grid's step is expressed in calendar units, the buckets it produces are not the same width: - a month covers 28, 29, 30 or 31 days; - a quarter covers 90, 91 or 92 days; - a year covers 365 or 366; - and a step built from any of these inherits the same unevenness. Nothing about this is a defect — a calendar month is the thing people actually want to report on. The defect is comparing the resulting totals as if the buckets were interchangeable. February is about **10% shorter** than a 31-day month, so a completely flat underlying rate produces a February figure about 10% lower, every single year, in every such series. ## What unequal width does to each kind of aggregate | what the bucket holds | sensitivity to bucket width | |---|---| | a sum of a per-day quantity | roughly proportional to width — the full effect | | a count of records | roughly proportional to width, for a steady arrival rate | | a mean over the records in the bucket | largely insensitive to width; it moves with what the records say, not how many days they span | | a maximum or a minimum | weakly sensitive — a shorter bucket has fewer opportunities to reach an extreme | | the last value in the bucket | insensitive, but stamped at a different position | The common mistake is to assume the mean is exposed the same way the sum is. A per-record mean is not a per-day quantity, so widening the bucket does not scale it; that is precisely why a rate is the repair for a sum. ## Three ways to make buckets comparable 1. **Normalise to a rate.** Divide each bucket's total by that bucket's own width — its own day count, not an average of 30. An average divisor leaves most of the distortion in place and adds a new one. 2. **Use an equal-width step.** A step of a fixed number of days produces buckets of identical width, at the cost that they no longer line up with calendar names anyone recognises, and they drift against month ends year on year. 3. **Compare like with like.** Hold the calendar unit fixed and compare across years — this February against last February — so width is constant by construction. Each costs something. A rate is comparable but is no longer the figure a report or an invoice states. An equal-width step is clean arithmetic but is answering a question nobody asked in those terms. Comparing year over year is honest but throws away the most recent comparison a reader wants. ## The end buckets are short for a different reason A bucket at either end of the span can be **partial**: the run happened mid-period, or the span started mid-period, so that bucket covers less time than the step declares. In a chart, a partial final bucket and a genuinely low one look identical, and the partial one is the more common of the two. Separate them explicitly: - compare the last stamp in the input with the closing edge of the final bucket; if the input stops first, the bucket is partial; - do the same at the leading edge for the first bucket; - mark partial buckets in the output, or exclude them, rather than leaving a reader to treat them as completed periods. Note that this is a *third* reason a bucket total can be low, alongside unequal calendar width and a genuine change. The three need separating before anyone draws a conclusion, and none of them raises an error. ## What to publish The safest habit is to publish the total as the fact and the rate as the comparison, side by side, with the bucket's width available as a column. That way the monthly figure stays the monthly figure, the comparison is done on something comparable, and nobody has to reconstruct the divisor from the stamps to check your work. A last caution on vocabulary: when you say "daily", "monthly" or "quarterly", you are naming a rule in a calendar, not a fixed quantity of elapsed time. The arithmetic above is the monthly case because it is the loudest, but the same caution applies at any size built from calendar units.