Time is a well-known source of trouble for programmers. We looked earlier at one type of time troubles: overflow. Today, I’d like to look at another time trouble: transitions.
Here are the problems we’ll see:
- Multiple transitions can occur at once
- You may go from one time to another with no intervening times
- You may have the same time repeat itself in a single day (and maybe more than once)
- Different geographies transition at different times rather than all together
- You may make errors because of complicated rules
Simultaneous Transitions
Different units of time are used for different purposes. Insurance companies have to look decades ahead, while a library may focus on days or weeks. A heart monitor might work at a sub-second level.
We have words for many of these time scales:
… eon, millennium, century, decade, year, quarter, month, week, day, minute, second, … millisecond, … nanosecond, …
Notice that these time scales aren’t perfectly nested, e.g., a single week may spread across two separate years.
If we need to monitor different scales at the same time, we have to be careful about the order of changes. For example, if you have a clock-calendar, what happens at midnight? Do you get notified of time and day changes in one event, or separately? If it’s separate, you might find yourself going from 11:59pm Jan 17 to 12:00am Jan 17 to 12:00am Jan 18. Or maybe it happens the other way around, 11:59pm Jan 17 to 11:59pm Jan 18 to 12:00 am Jan 18.
You’ll need to consider the design (e.g., get a single event, and derive the larger scale unit from the smaller). You’ll also want to consider tests of the transition itself. Can you ever produce an illegal time or date, particularly during a transition?
Geographic Inconsistencies
Calendars are notorious for their difficulty.
Where I live, some people celebrate “Old Christmas” on January 6, twelve days after “modern” Christmas on Dec 25. This happened because of the shift from the Julian calendar to the Gregorian: a twelve-day shift for these folks. That shift was a drawn-out process: 1582 in Italy, 1752 in England, and into the twenty-first century for others.
If you’re comparing dates to find out “when” something happened, you also have to know which country it happened.
Daylight Savings Time
Different countries use different schemes for Daylight Savings Time. So do different states – and some don’t use it at all. And even those that use DST have different approaches.
DST does two odd things:
- “Spring forward in the spring” – In the US, we jump from 2:00am to 3:00am with no intervening time. Other countries use a different approach – of course:) And south of the equator, they “spring forward” in the fall.
- “Fall backward in the fall” – In the US, we jump from 2:00am to 1:00am, then have the hour from 1:00 to 2:00 a second time.
This gets complicated between time zones in the US: we’re spread across multiple time zones, so you get a cascade effect as time zones switch one at a time.
Between countries, the bigger challenge is that different countries switch at different dates. So you have to be very careful when you schedule international meetings – pushing it out a week can also make it be at a different time.
Testing:
- Notifications: How will you handle notifications in that clock transition time – will you report a 2:30am event during the spring DST change? Or skip it because 2:30 never happened. Will you report a 1:30 am notification twice in the fall?
- Testing across time zones and countries: you need to check things that happen before, during, and after the shift.
Time Zone Shifts
Time zones have a similar issue: your clock usually changes as you shift zones.
It often takes a while for devices to notice the shift. When I was traveling a lot, I learned to use the airport monitors to check the time, not my phone, until I was sure it had caught up.
Things being in different time zones can create issues: For a while, I used a habit tracking app. On a trip to China (with a 12 hour time difference), the app (or its servers?) stayed on the home time zone – leaving me very little time to get things done.
Like Daylight Savings Time, time zones can also have it so a time never happens, or happens twice. Again, you need to test before, during, and after the transition. There’s nothing that says it has to be a one-hour gap, either.
Other Transitions
Not all problems are caused by geography. Some are caused by individual users’ activities.
Users Changing the Clock
Sometimes, users need to change the clock. Certainly, this happens if you’re testing the things mentioned earlier – you set a clock earlier or later to stimulate a transition. But it can happen for other reasons too. I’ve twice had a cell phone lock in on the wrong time. Unfortunately, once was when I was teaching and I didn’t realize the discrepancy until lunch time. I forced it to the right time until it caught up:(
There are usually at least two modes for time: manually set by the user, or set automatically by network time. Neither is perfectly accurate.
System State Changes
Some activities, or in some cases some inactivities, can affect timers and clocks: system sleep, shutdown, and restart (in all their various incarnations).
When your computer sleeps or shut downs, it again creates a situation where some times never happen, or happen multiple times, for a running application. I once helped test a time-based app that relied on “tick” notifications, and we learned that it needed to modify its approach to deal with sleep and shutdown.
This issue sometimes shows up as CPU vs wall time: an application may consider itself to run for a certain time, but this may not account for all the time a user was waiting. You see this all the time with unit tests – the tests may claim they ran in 0.5 seconds, but you were definitely waiting for many seconds.
Programmer Error – Leap Years
Other time-related rules have given people trouble, but leap years have been a problem for many systems.
Leap years happen because of differences in the theoretical and actual (solar) year – we add a day every four years (unless it’s a year ending in 00, except every 400 years).
As “complicated” goes, the rules aren’t that bad – but with a computer you can affect lots of people. On one side, people have gotten it wrong for years in the past. For example, Microsoft Excel assumed that 1900 is a leap year (it wasn’t). (Lotus 1-2-3 and Microsoft Multiplan made the same mistake.) So, dates before March 1, 1900 are incorrect. And if you’re trying to map dates from there to a system that gets it right, you have to adjust prior dates.
This doesn’t matter for forward-looking spreadsheets, but if you’re maintaining a list of historical dates, they might be off by a day.
Leap year was an issue for the year 2000 – albeit a small part of the Y2K problem. There were applications that got the 100-year part of the rule right (handling 1900 correctly:), but they didn’t handle the 400-year rule (and didn’t realize that 2000 was a leap year).
I probably won’t be here in 2400 to see how that one goes.
For testing, you need to make sure you understand the rules correctly, and check that years got properly mapped. You want to make sure there are no anomalies like February 30.
Conclusion
We looked at several ways that transitions make trouble for those who must think about times and dates.
From a testing perspective, three things stand out for me, that you need to:
- Understand the rules/requirements deeply
- Be aware of ways the many transitions that can make trouble
- Test situations before, during, and after these transitions and anomalies
I hope your time troubles are few!
References
“Excel incorrectly assumes that the year 1990 is a leap year”. https://learn.microsoft.com/en-us/office/troubleshoot/excel/wrongly-assumes-1900-is-leap-year . Retrieved 2024-01-31.
“Falsehoods programmers believe about time”, by Tim Visée. https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca . Retrieved 2024-01-31.
“Gregorian calendar”, Wikipedia. https://en.wikipedia.org/wiki/Gregorian_calendar . Retrieved 2024-01-31.
“Time Troubles – Binary Timer Overflow”, by Bill Wake. https://xp123.com/time-troubles-binary-timer-overflow/. Retrieved 2024-01-31.