Common Time-Related Bugs and Protection Strategies in Software Development

On the day when 2022 handed over to 2023, the author reflects on typical time‑related cases that developers encounter, especially during special periods such as New Year or month‑end, and shares defensive measures for each case.

Category 1: Time Conversion Issues

Scenario: A user in China places an order at midnight on May 20th using a cross‑border e‑commerce app. The order screenshot shows the time as May 19th, suggesting a “time travel” problem.

Cause: The backend stores timestamps in the server’s time zone (e.g., a foreign country), while the frontend displays the raw value without converting it to the user’s local time zone.

Protection:

Development: Ensure front‑end and back‑end use the same time zone when converting timestamps to human‑readable dates. Use UTC+8 (Beijing) as a common base, and when parsing strings, prefer time.ParseInLocation to specify the location.

Testing: Switch the client/web application’s time zone and verify that displayed times match product requirements.

Category 2: Daylight Saving Time (DST) Issues

Scenario: A user enters a birthdate of July 8, 1986 to calculate age and horoscope, but the computed age is always one hour ahead.

Cause: China observed DST from 1986 to 1991. During DST periods, clocks were advanced by one hour, causing a one‑hour offset for dates that fall within those ranges.

Protection:

Development: Maintain a list of DST date ranges (e.g., 1986‑05‑04 to 1986‑09‑14, 1987‑04‑12 to 1987‑09‑13, etc.) and adjust calculations accordingly. When a timestamp falls on the DST start day at 00:00, add one hour; during DST, subtract one hour to revert to standard time.

Testing: Include test cases that cover DST start and end days, which may have 23‑hour or 25‑hour days.

Category 3: Time Precision Issues

Scenario: After watching a video for 1 minute, the user’s watch history shows 1 hour of viewing time.

Cause: The backend returns time values in seconds, but the frontend mistakenly formats the value as hours.

Protection:

Development: Clearly define conversion formulas for time units (nanosecond, microsecond, millisecond, second, minute, hour) and ensure the front‑end applies the correct unit.

Testing: Verify that time units are consistent (s, ms, min, h, day) and test edge cases such as year‑end, month‑end, and day‑end transitions.

Category 4: Time Comparison Issues

Scenario: An OA system shows no meetings when comparing “yesterday 15:00” with “today 15:00”, leading to a missed contract.

Cause: The two timestamps are in different time zones (e.g., Beijing vs. US), so the comparison fails.

Protection:

Development: Use comparison functions that normalize timestamps to a common base (e.g., compareTime.Before , compareTime.After ) regardless of time zone.

Testing: Design test cases for same‑day, cross‑year, cross‑month, cross‑day, and cross‑day‑boundary comparisons.

Category 5: Time Storage Issues

Scenario: During the “Y2K‑2022” bug, some Exchange servers stored dates using a signed 32‑bit integer ( yymmddHHMM ) that overflowed on 2022‑01‑01 00:00.

Cause: Using only two digits for the year (or a limited integer range) caused the system to misinterpret the year as 1900 or overflow the numeric field.

Protection:

Development: Choose appropriate MySQL data types— TIMESTAMP (stores timezone‑aware time), DATETIME (stores formatted string without timezone), or TIME for hour‑minute‑second values. Ensure the chosen type can represent the required range.

Testing: Create test cases that verify correct storage and retrieval for the selected time type.

Category 6: Time‑Based Permission Issues

Scenario: On the first day of 2023, an employee’s badge cannot be recognized because the system’s permission window expired at 2022‑12‑31 23:59:59.

Cause: The time‑based permission feature did not account for expiration, causing the authorization to fail.

Protection:

Development: Design permission logic to handle edge cases, such as adding black‑/white‑lists for emergency scenarios.

Testing: Include test cases that cover both within‑range and out‑of‑range timestamps.

Operations: Implement monitoring and alerting for permission‑related time windows to detect issues early.

In summary, the article outlines six typical time‑related cases, their root causes, and defensive strategies for developers and testers. The author plans to continue sharing more insights in future posts.