Learning Objectives
- Understand how zero-duration date intervals trigger division-by-zero errors in rate calculations
- Distinguish between ArithmeticException, NaN, and Infinity across different programming languages
- Design test cases that target zero-interval edge cases in date-dependent formulas
The Problem: Rates That Divide by Duration
Many financial and scheduling features calculate a per-unit rate by dividing a total by a duration derived from two dates:
daily_fee = total_cost / (checkout_date - checkin_date)
hourly_rate = project_budget / (end_datetime - start_datetime).hours
interest = principal * rate / days_between(start, end)
These formulas work correctly when the interval is positive. But what happens when start == end? The denominator becomes zero, and the behavior depends entirely on the language and data type involved.
Language-Specific Behavior
| Language / Type | Result of n / 0 | Behavior |
|---|---|---|
| Java (int / long) | ArithmeticException |
Throws, crashes if uncaught |
| Java (double) | Infinity or NaN |
Silent, propagates through calculations |
| JavaScript (Number) | Infinity or NaN |
Silent, may render as "Infinity" in UI |
| Python (int) | ZeroDivisionError |
Throws, crashes if uncaught |
| Python (float) | inf or nan |
Silent, propagates |
| SQL (integer division) | Division by zero error | Query fails, may cause HTTP 500 |
The silent cases are particularly dangerous. If JavaScript calculates NaN and stores it in a price field, the user may see NaN € or $NaN in the UI — a confusing, broken experience that is easy to miss in testing if no one thinks to enter equal dates.
What Zero-Duration Scenarios Look Like
Zero-duration intervals occur more often than you might expect:
- A user selects the same check-in and check-out date in a hotel booking form
- A subscription starts and ends on the same day (one-day trial)
- A project task is created with identical start and end timestamps (accidental double-click)
- A billing cycle end date equals its start date due to a timezone conversion edge case
Testing Strategy
When testing any feature that computes a rate, fee, or ratio using date arithmetic:
- Enter identical start and end dates — the classic zero-interval test
- Enter start = end at midnight — timezone edge case
- Observe the full response: HTTP status, response body, any UI display of the computed value
- Check the server logs for ArithmeticException, division by zero, or NaN warnings
- Verify the error is handled gracefully — a user-friendly validation message, not a 500 error
A well-designed application should validate that end > start before performing any division, returning a clear error message like "Check-out date must be after check-in date." The absence of this validation is a bug.