Calculator Date and Proration Test Matrix

Direct answer

Test date and proration calculators with a versioned date contract, not just example dates. Name the calendar, time zone, boundary inclusivity, billing anchor, roll rule, denominator and rounding boundary; reject impossible or reversed ranges; and test calendar-day counts separately from elapsed hours at leap-day, month-end and daylight-saving boundaries.

What must a date or proration calculator define?

Choose each policy before writing the formula. Store the policy version with the result so future corrections and billing replays use the same interpretation.

DATE-PRORATION-TEST-MATRIX

What did the sixteen calendar and proration fixtures test?

The fixtures execute a small reference implementation with strict YYYY-MM-DD validation, UTC-based calendar-day arithmetic and explicit-offset elapsed-time examples. They do not claim to validate every date library or billing platform. All sixteen returned the documented result on 18 October 2026.

Why is a local day not always 24 hours?

For calendar products, count local dates under the chosen boundary convention. For elapsed-duration products, compare instants. Across New York's spring 2026 offset change, local midnight on 8 March (-05:00) to local midnight on 9 March (-04:00) is 23 elapsed hours. Across the autumn change, 1 November (-04:00) to 2 November (-05:00) is 25 hours.

ECMAScript's current specification says local-time conversion uses the political standard-time and daylight-saving rules in effect and recommends IANA zone information for time-zone-aware implementations. Record the runtime and zone-data version used for a result that depends on those rules.

What does an offset prove—and what does it not prove?

RFC 3339 timestamps express an instant with a relationship to UTC. The offset in `2026-03-08T07:00:00-05:00` is enough to preserve that instant, which equals `2026-03-08T12:00:00Z`. It is not enough to infer that the source meant America/New_York or to calculate that location's future rules.

If a product schedules by local civil time, retain a named IANA zone in addition to the resolved instant and offset. If it only records an instant, do not invent a location from the offset.

Worked example: actual-days versus fixed-30 proration

A fictional $310 monthly service starts on the 21st of a 31-day period and uses an inclusive start with an exclusive next-period boundary. Eleven eligible days remain, so an actual-days policy calculates $310 × 11 ÷ 31 = $110.00.

A separately disclosed fixed-30 convention calculates $310 × 11 ÷ 30 = $113.666…, displayed as $113.67 under the example rounding rule. The difference comes from policy, not arithmetic error. The interface, invoice, CRM record and follow-up must carry the same denominator and amount.

How should month-end anchors and rounding reconcile?

An anchor on the 29th, 30th or 31st needs a roll rule for shorter months. The reference fixture uses the last valid day; next-valid-day and rejection policies are possible alternatives, but none should be inferred silently.

Keep unrounded allocations until the documented monetary boundary. If three separately rounded lines each show $33.33, their $99.99 sum differs from a $100.00 total rounded once. Define where the balancing cent goes and preserve both the unrounded allocation and reconciliation decision.

Date and proration calculator release checklist

Release only when the visible result and every downstream value share the same date contract.

• State the calendar, named zone or offset-only model and zone-data version.
• Name start and end inclusivity and reject reversed ranges.
• Reject impossible dates instead of normalizing them silently.
• Separate calendar-day counts from elapsed-hour calculations.
• Test common years, leap years, month ends and both DST transitions.
• Define the billing anchor, roll rule and proration denominator.
• Round at a named boundary and reconcile line items to the total.
• Replay affected fixtures when runtime, library or zone data changes.

Verification and correction path

The three primary sources and all sixteen deterministic fixtures were checked on 18 October 2026. IANA 2026e was the latest published zone-data release and included a future Manitoba rule change, demonstrating why a stored zone-data version matters. If a result appears wrong, use the correction form and include the calendar dates, zone or offsets, boundary convention, billing anchor, denominator, runtime, zone-data version and expected amount.

Method and evidence

Evidence type: Versioned date contract, calendar-versus-duration decision table, worked proration example and sixteen executed deterministic fixtures

1. Defined the calendar, named zone, start and end inclusivity, billing anchor, denominator, precision and rounding boundary before evaluating a result.
2. Separated calendar-date arithmetic from elapsed-time arithmetic so daylight-saving transitions cannot silently turn a local day into an assumed 24-hour duration.
3. Executed sixteen deterministic fixtures covering same-day boundaries, month and leap-year transitions, invalid dates, month-end anchors, 23- and 25-hour local days, explicit offsets, proration denominators and rounding reconciliation.
4. Rechecked RFC 3339, the IANA Time Zone Database release 2026e published 29 September 2026 and the current ECMAScript Date specification on 18 October 2026.

Topic score: 4.66 / 5. Business fit 4.8, verified demand 4.5, distinct intent 4.7, original evidence 4.9, citation usefulness 4.6, feasibility 4.4.

Primary sources

• IETF RFC 3339 ↗Standards-track Internet timestamp profile covering Gregorian dates, UTC relationships, numeric offsets and the distinction between timestamps and intervals; checked 18 October 2026.
• IANA Time Zone Database ↗Primary maintained location-based civil-time data; latest release 2026e was published 29 September 2026 and checked 18 October 2026.
• ECMAScript Date Objects ↗Current language specification for Date parsing, local-time conversion, offset changes, repeated/skipped local times and recommended IANA data use; checked 18 October 2026.

Limitations

• This is an implementation and testing model, not billing, accounting, payroll, tax, contract or legal advice.
• Contracts, jurisdictions and providers may prescribe a different day-count convention, notice rule, billing anchor, tax treatment or rounding method.
• Leap seconds, non-Gregorian calendars, sub-millisecond precision and named-provider invoice behavior are outside the matrix.
• The DST fixtures use explicit 2026 New York offsets and the zone-data version check is deterministic; the suite does not certify every runtime's bundled time-zone data.
• No live billing platform, named calculator builder, third-party date library, browser, assistive technology or production dataset was tested.

Related research

• Calculator rounding and precision policy
• Calculator unit-conversion test matrix
• Calculator release test matrix
• Calculator formula versioning
• Calculator result reconciliation
• Corrections policy