CGrates Time Rules Taught Me to Test Billing Schedules Like Code

Recurring charging rules look harmless until timezone, month-end and relative-time semantics collide.

By Reaz Romen✓ Site verified

Lab period February 2025 Published 2025-03-20 1 min read

Lab Note. Reconstructed in 2026 as a technical lab note from the 2025 voice, telecom and infrastructure study period. The archive date indicates the period covered; the current site publication date is shown separately.

Charging systems contain an uncomfortable amount of time logic. Expiry, recurring actions, monthly resets and delayed changes can all depend on date parsing and timezone behavior.

I stopped treating those values as configuration strings and started testing them like code. For each schedule I wanted a fixed input time and a predictable next execution time. Month-end rules deserve special attention because February, leap years and local timezone offsets can expose assumptions that daily rules never hit.

This is especially important in rating systems because a schedule bug is not just a failed job. It can apply the wrong price window or leave balances in the wrong state. A small table-driven test around time expressions was more valuable than repeatedly checking the live scheduler after a change.