Common Time-Related Bugs and Protection Strategies

The author shares practical experiences with frequent time‑related issues that arise in web and backend systems, summarizing six major categories and offering protection methods for both development and testing phases.

1. Time Conversion Cases

Scenario: An e‑commerce app displays an order time one day earlier because the backend stores timestamps in the server's local timezone while the frontend shows them without conversion.

Root Cause: Mismatch between server‑side timezone (e.g., UTC+8) and client‑side display.

Protection: Ensure consistent timezone handling during timestamp formatting; use time.ParseInLocation to specify the desired zone instead of the default UTC.

2. Daylight Saving Time Cases

Scenario: A user’s calculated age is consistently one hour off because the date falls within historical DST periods in China (1986‑1991).

Root Cause: The system does not account for DST date ranges, leading to a one‑hour shift.

Protection: Maintain a list of DST intervals (e.g., 1986‑05‑04 to 1991‑09‑14) and adjust timestamps accordingly; test edge cases where a day may have 23 or 25 hours.

3. Time Precision Cases

Scenario: A video‑app returns duration in seconds, but the frontend mistakenly formats it as hours, causing a 1‑minute video to appear as 1 hour.

Root Cause: Mismatch between the unit of the value returned by the API (seconds) and the unit used for display (hours).

Protection: Convert units correctly using the standard hierarchy:

Nanosecond = 1
Microsecond = 1000 * Nanosecond
Millisecond = 1000 * Microsecond
Second = 1000 * Millisecond
Minute = 60 * Second
Hour = 60 * Minute

Test that the time unit is consistent across the stack and cover cross‑year/month/day scenarios.

4. Time Comparison Cases

Scenario: An OA system shows no meetings when comparing yesterday 15:00 (Beijing time) with today 15:00 (U.S. time).

Root Cause: Comparison performed without a unified reference point, mixing different timezones.

Protection: Use a common epoch (e.g., UTC) for all comparisons; employ functions like compareTime.Before and compareTime.After that operate on normalized timestamps. Test across 24‑hour, cross‑day, cross‑month, and cross‑year boundaries.

5. Time Storage Cases

Scenario: Legacy “Y2K‑like” bugs appear when storing dates as two‑digit years or as signed integers that overflow after 2022.

Root Cause: Inadequate date representations (e.g., YYMMDDHHMM stored in a 32‑bit signed integer) cause overflow or misinterpretation of the year.

Protection: Choose appropriate MySQL column types: TIMESTAMP (stores timezone‑aware values), DATETIME (stores formatted strings without timezone), or TIME for hour‑minute‑second components. Test storage choices against functional requirements.

6. Permission Cases

Scenario: An employee’s badge cannot be recognized because the access permission expires at 2022‑12‑31 23:59:59, and the system does not handle post‑expiry checks.

Root Cause: Time‑based permission logic lacks handling for expiration and does not provide fallback or alerts.

Protection: Design permission modules with explicit validity windows, support black‑/white‑lists for emergency overrides, and add monitoring/alerting for upcoming expirations. Test both in‑range and out‑of‑range timestamps.

Conclusion

The six categories of time‑related cases illustrate common pitfalls in software development; applying the suggested design and testing safeguards can significantly reduce bugs caused by timezone, DST, precision, comparison, storage, and permission issues.