Daylight Saving Time (DST)
// Definition
The practice of advancing clocks by one hour during warmer months and reverting them in autumn, creating two critical testing edge cases: the spring-forward transition, where one local hour does not exist, and the autumn fall-back, where one local hour occurs twice. Any system that stores, compares, schedules, or displays timestamps must be tested at these instants. Common failures include scheduled jobs skipping or running twice, timestamps stored in local time becoming ambiguous after fall-back, and duration calculations spanning a transition returning incorrect values. The safest approach is to store all timestamps in UTC and convert to local time only at display. Transition dates vary by region and change periodically by legislation — derive them programmatically rather than hardcoding.
// Related terms
Time Zone Handling
The set of logic that converts timestamps between UTC (the storage standard) and local display times, accounting for UTC offsets and Daylight Saving Time transitions. Common bugs: dates shifting by one day at midnight when local offset is applied, DST gaps causing a time to not exist (2:30 AM on spring-forward night), DST ambiguity causing a time to appear twice (1:30 AM on fall-back night), and inconsistent display between server-rendered and client-rendered timestamps. Test strategy: cover at least one timestamp near a DST boundary, one at midnight UTC, and one for a user whose local offset crosses the date line.
ISO 8601
An international standard that defines unambiguous string representations for dates, times, durations, and intervals, eliminating locale-specific ambiguity (01/02/03 means different dates in different countries). The canonical format for a datetime instant is YYYY-MM-DDTHH:mm:ss.sssZ, where T is a literal separator and Z indicates UTC; offsets are expressed as ±HH:mm (e.g. +05:30). QA relevance: use ISO 8601 strings in all API test fixtures and test data to avoid parser ambiguity across systems and locales; assert that APIs return ISO 8601 timestamps rather than locale-specific strings; and be aware of edge cases at leap-year February 29 boundaries and DST transition instants where a naive local-time string is ambiguous or non-existent.
Leap Year
A year with 366 days that adds 29 February to keep the calendar aligned with Earth's orbit. The rule: a year is a leap year if divisible by 4, except years divisible by 100 are not leap years — unless also divisible by 400 (2000 was a leap year; 1900 was not). This three-part rule is a frequent source of off-by-one bugs: developers who only check divisibility by 4 will incorrectly treat 1900, 2100, and 2200 as leap years. In QA, 29 February is a canonical boundary-value test case for any date field: it should be rejected in non-leap years and accepted in leap years. Systems that compute ages or date differences must also handle the February 29 to March 1 transition in non-leap years correctly. The unambiguous formula is: (year % 4 === 0) && (year % 100 !== 0 || year % 400 === 0).