TECH Signal 395
Counting the days, revisited
↗
Illustration only Photo by Martí Sierra on Unsplash
The article revisits an integer-only algorithm for converting Gregorian dates to a linear day count, presenting a refined version that avoids overflow and improves compiler optimization.
Engineers who maintain date-time libraries can now support a wider range of years without risking integer overflow, while also benefiting from faster generated code. The changes illustrate how small arithmetic tweaks can enhance both safety and performance in low-level date calculations.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
The revised formula shifts January and February to the previous year so that leap-day handling aligns with a repeating five-month pattern, enabling a compact month-offset term.
Splitting the leap-year term y*1461/4 into y*365 + y/4 - y/100 + y/400 prevents overflow on 32-bit ints for large year values.
Replacing the month offset m*153/5 with m*979/32 gives compilers a single multiply-and-shift operation that is faster and works within the limited range of m.
THE READ
What the cluster adds up to.
The core change is the month-year adjustment that moves January and February to the end of the preceding year, which makes the leap day of year 4 fall exactly where the algorithm expects it. This adjustment also allows the month offset to be based on a repeating five-month pattern that starts in March. By aligning the epoch with this pattern, the formula can count days before a month using a simple linear term.
The original version combined the leap-year contribution into y*1461/4, which overflows for large year values on typical 32-bit ints. The revised expression separates the terms into y*365 + y/4 - y/100 + y/400, each of which stays within safe bounds for the same integer width. This eliminates the overflow risk without requiring a wider type.
For the month offset, the author switched from m*153/5 to m*979/32 because the latter compiles to a single multiply-and-shift on modern CPUs, whereas the former needs two multiplications and does not benefit from the known limited range of m. The two fractions produce the same day pattern for the adjusted month numbering, so the substitution is functionally equivalent.
The algorithm still depends on an epoch choice; the text shows how to shift the offset to obtain the Julian day, modified Julian day, or Unix epoch values. However, the implementation remains limited by the width of the integer type used and by the semantics of signed division on the target CPU, meaning it may not work correctly for proleptic Gregorian dates far before year 1 if the underlying type cannot represent those values.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER