Managing time and date values is always a fun trick, for some value of fun. First, UTC is your friend. Embrace it and hold it close. Use it whenever manipulating or comparing time date values. With few exceptions, translation to local time should be reserved for user display. Luckily, most modern operating systems have well developed standard ways of managing date times. Use them. Don’t roll your own without a very good reason. No, one better than that. Anyway, that’s the easy part
Now imagine an app with time and/or date based business rules. Your user should do something every 4 hours, or shouldn’t do something more often than once a day. You store the starting date time and then you compare it to the current date time. But what if your user hopped in a plane and flew across the country, or across the international date line. Were your business rules designed to take travel into account? If a user takes a daily action at 11:59pm, should they be allowed to repeat it at 12:01am? Sometimes the answer is yes, and sometimes the answer is no, but it needs to be solved at the requirements level, not the implementation level. Always look for the edge cases when dealing with date time related business rules and try to decide how (or if) to deal with them before you start implementation.
Now remember that when you’re relying on the system time on the device, that’s a value the user can change at will, even while in the middle of using your app. Is this something that needs to be taken into account in the design? Maybe it’s just let the user deal with any fallout. But if there’s anything security or access related triggered by time, then you need to be ready for users who get their devices to lie to you. (Hey, at least it means they’re using the app, right?) Often the solution to this is that the master time is calculated by your server which the device has to check into. Some users will play thee games maliciously. Some will do it out of curiosity. Just be aware that it can and will happen.
Then there’s the problem of testing apps implementing business rules that span days (or weeks or months). It’s seldom feasible (or reasonable) to read testing out over that span of time, so why not just roll the time forward or backward on the device? Time travel! Except that, unless it’s a dedicated test device, you might run into unwanted side effects. One possible way to get around some (but not all) of those potential side effects is to roll the time back into the past before you start your test, working your way toward the present.
But as soon as your app has to publish to a server, your test results are likely to be problematic. Again, depending on the design. It’s easy to change the time on a device. It’s not to simple to arrange getting the time changed on a server unless it’s an isolated and dedicated server. Even when it isn’t a problem to time shift on the device and publish to a server, we ran into a real life case where our testing time shift crossed the boundary of an SSL certificate renewal. Odd things can trip you up. Be on the look out.
One of my favorite techniques for dealing with business rules that cover large periods of time is to do test builds that substitute a shorter unit of time; seven days becomes seven minutes, or ten hours become ten minutes. A simple substitution of time units makes it easier to set up the test situation with a simple toggle in the code. Please don’t depend on going in and manually updating every substitution every time you change in and out of test mode as you will eventually miss one.
Happy coding!
Sam Herdman 