![Time Check](https://gratis-creeper.transforms.svdcdn.com/staging/blog/059_0U0A2229_Edit-squashed.jpg?w=3075&h=2021&auto=compress%2Cformat&fit=crop&dm=1708017348&s=2991ae18a38c594ac0abc4519791cd02)
The Discovery
Our team was working on a release candidate for a client when we ran into a simple problem, one that could be found on any list of programming falsehoods. This is when things got interesting. In addressing what was believed to be the problem, we ended up masking the real issue.
“I’m getting an error when checking in”
Defects are normal. Truth be told, we almost look forward to submitting a release candidate and getting a laundry list of things to fix. It’s part of the process. While we do our best, inevitably there’s something we missed.
On this particular day, the error seemed innocent enough; however, reproducing it proved challenging. We couldn’t isolate an issue that would cause the app to fail on our end, much less catastrophically and consistently.
We can thank our contacts and QA team for sticking with us as we worked together to find a solution. Many theories and several hair-pulling hours later, we landed on it.
“Could it be a time difference?”
The question came completely out of the blue. We hadn’t considered time up until this point. Then again, if you throw enough theories at the wall, one is bound to stick.
“Does your device say it’s 2:53pm right now?” we asked.
It should not have come as a total surprise when our QA team member responded “2:50.” After all, anyone can set their device back 3 minutes. “Oh yeah, I remember I did that a long time ago for scheduling concerns.”
And just like that…catastrophic failure
The Problem
Our API design was twofold:
- The server would track activity any time the app makes a request using its local timestamp
- In cases where an app encounters a network error the request would be cached. On certain endpoints, the backend would accept a timestamp from the device “when the request was first created” rather than relying on the time the request was received by the backend itself.
This can only work if a developer relies on item #14 from the list of falsehoods about time (part 1).
“The server clock and the client clock will always be set to the same time.”
The hard truth? Clocks are inconsistent, time zones are fickle, and phones can’t be trusted. It’s probably not ideal to design an API that relies on its own time for tracking purposes, and expects all clients to have clocks to match. In the event that the device reported an event “too early,” the backend would return an error. We were just now learning that our app would need to tolerate such an occasion gracefully.
The mitigations
Our client was in a unique position to enforce date and time settings for their controlled release and userbase
Handle the error app side gracefully
Trust that the device’s clock is consistent with the server moving forward, and would cease reporting events happening “from the past” compared to the server
The fix
While changes to backend design can be tricky, there’s often no other remedy for flawed design. Rather than having the device send the timestamp of the relevant event in the request, we would have it send the delta of “how long ago the request occurred.” The delta would start at 0, incrementing after a request fails to send.
Pros:
The server can simply rely on its own clock for all time values, minus the incoming delta
If the app encounters network trouble or the request initially fails to send, the app can hold the request for as long as it wants while incrementing the delta
Only one device is concerned with the time on the wall
Cons:
All apps consuming the API would need to be updated
The user might still be able to adjust the date and time settings while the app is locally maintaining its delta
Falsehood about time #22: “The duration of one minute on the system clock will be pretty close to the duration of one minute on most other clocks.”
The fix for the first edge case would likely involve relying on a library to manage time independent of the device’s system clock while offline to maintain an accurate delta, one that the user would be less likely to obstruct or alter.
Ultimately, clock drift will need to be dealt with in another manner and may not be a business concern. In this case, problem solved.
Looking for more like this?
Sign up for our monthly newsletter to receive helpful articles, case studies, and stories from our team.
![UX Writing Tips](https://gratis-creeper.transforms.svdcdn.com/staging/blog/UX-Writing-Tips.jpg?w=696&h=320&q=75&auto=format&fit=crop&dm=1708017708&s=83114e23adbaa2c02b8fed21ebb236e7)
UX Writing Tips
February 3, 2023Kai shares a few tips he's collected on how to write for user interfaces.
Read more![MichiganLabs’ approach to product strategy: Driving software success](https://gratis-creeper.transforms.svdcdn.com/staging/blog/approach-to-product-strategy-thumbnail.png?w=1200&h=1200&auto=compress%2Cformat&fit=crop&dm=1708017425&s=fcad451dff0b676c36748aae877710cc)
MichiganLabs’ approach to product strategy: Driving software success
February 12, 2024 Read more![Build what matters: Prioritize value over feature count](https://gratis-creeper.transforms.svdcdn.com/staging/blog/value-delivery-thumbnail.jpg?w=1080&h=1080&auto=compress%2Cformat&fit=crop&dm=1722534218&s=7e3eb61ab73a30709d5d40f227777492)
Build what matters: Prioritize value over feature count
August 1, 2024Focusing on value delivery—rather than just feature count—combines your business goals with your users’ needs to achieve real software ROI.
Read more