Dates worth testing
Software does not break on ordinary Tuesdays. It breaks on the last day of the quarter, on 29 February, at the moment a year rolls over, and one second after a licence expires. These are the dates that find those bugs - 14 of them ship as named scenarios.
Period boundaries
Anything that closes a period, numbers a document by year, or accrues to a cut-off gets these wrong first.
- Last day of month - does month-end closing and period accrual behave on the last day of the month?
- Last day of quarter - does quarter-end closing and reporting behave on the last day of the quarter?
- Last day of fiscal year - does the app close the fiscal year on the right day, the day before the fiscal year starts?
- Year rollover, live - does document numbering, year-in-name and annual reporting handle the rollover while it happens, rather than being restarted afterwards?
The last one is the one people usually cannot test at all, because it needs the clock to cross midnight on 31 December while the application is running. That is a ten-second job with an accelerated clock.
Calendar and representation edges
- 29 February - the leap day that exists only every four years, and that a surprising amount of validation code rejects outright.
- Unix epoch zero - does the app treat 1 January 1970 as a real date, or as an empty value it should have refused to store?
- 2038 boundary - the moment a signed 32-bit
time_truns out, at2038-01-19T03:14:07Z. One second later the counter overflows into 1901.
Licences, trials and installation
These are for testing your own licensing, which is the case they were written for.
- Last day of trial - does the app still work in the very last moment of the trial?
- First day after trial expiry - does it refuse access the moment the trial ends, and how? A sensible message, or a stack trace?
- Licence expired a year ago - does it handle a licence that expired long ago, not just yesterday?
- Date before installation - does it behave when the clock is set before its own installation date? This one reads the target's own file date, so it needs no parameter.
Business rules and clock behaviour
- Payment due, +N business days - does a payment due N business days out land on the right day, skipping weekends and the right country's holidays? The only scenario that needs a calendar, and the answer differs between markets.
- Age-of-majority boundary - does the app admit somebody exactly at the boundary, and refuse somebody one day short?
- Clock skew, +90 s - does the app cope when its clock runs ninety seconds ahead of real time? This is the case that breaks time-based one-time passwords and token validation.
Using one
A scenario is a named date expression. The calculator works out what it means, and the substitution runs an application at it - the same name in both places.
# What date is it, and what does that date test? chrono calc --preset month-end # Run an application at it chrono run "C:\apps\test.exe" --preset year-rollover --report session.txt # The trial scenarios take the start date from the target's own file date chrono run "C:\apps\test.exe" --preset trial-first-day-after
In the window they are chips above the date field - one click fills it in. Each carries its own sentence saying what it catches, which is the part an online date calculator has no way to give you.
What is not here
The daylight saving transitions. Forcing an application through the spring-forward or fall-back boundary is a genuinely useful test and it is deliberately absent, because the session time zone is a fixed offset with no daylight saving - there is no transition to simulate yet. Shipping a scenario that quietly did nothing would be worse than not shipping it.
It comes back with a model of time zone rules. What the time zone does and does not do →