This article covers:
- What Exactly are Dates?
- Storing and Transmitting
- How do Date-Time Go Wrong in Integrations?
- Best Practice
What Exactly are Dates?
As an HR system, intelliHR stores dates for various reasons: to mark when someone commences employment, someone’s date of birth and so on. While we use dates all the time in our every day life, we’re actually describing a date relative to our timezone and the timezone of the event.
The biggest misunderstanding about time is that human-readable dates can be specified in universally understood formats such as 05/07/11.
For example, if I ask you to send an email tomorrow at 3pm, and I am in timezone A and you are in timezone A, we both immediately understand what tomorrow means.
However, if I ask you to send an email tomorrow at 3pm, and I am in timezone A and you are in timezone B, tomorrow at 3pm may occur at a different time for you. If timezone B is 1 hour ahead of timezone A then do I mean mean 3pm in timezone A, or 3pm in timezone B?
In this way, while we use “dates” all the time, they do not exist. We are implicitly always using date-times, where we anchor the date to a time relative to our timezone.
A timezone is a region with a certain offset, usually hours, from Universal Time, which is time (excluding daylight savings) in Greenwich, England.
Computers need to remember the timezone of date-times, and store these offsets to determine how to save a date-time. In our example, let’s say timezone A is Greenwich and timezone B is 1 hour ahead. Timezone B would be UTC+1:00.
These offsets help computers to decide how to display a date-time in the system correctly for your timezone as a user logging in to the platform.
Storing and Transmitting
When it comes to transmitting date-times between systems, it can get complicated quickly.
Let’s say we have two systems, intelliHR and my payroll system. If a user in Brisbane (UTC+10) logs into intelliHR and sets a first day of job date as Friday the 1st of May, what should a user in London viewing this start date (UTC+0) see? You’d think the 31st of April because technically if the employee starts work at 9am on a Monday in Australia that is **the 31st of April in the UK, but that doesn’t quite make sense, because they did start on the 1st of May regardless of where you are viewing the date from so neither are correct in every context.
To work through this complexity, most modern systems follow the standard of storing and exporting date-times as UTC date-times. This means that regardless of what a particular user sees in intelliHR, a date-time can reliably be exported via the API and sent to my payroll system that also stores date-times as UTC.
How do Date-Time Go Wrong in Integrations?
Put simply: time is difficult. Clocks can change, they can become un-synced with other clocks, and weird events can happen requiring changes: a country might change their offset without your knowledge, others change their offset on a schedule, referred to as daylight saving time.
Not only that, but if you’re integrating several systems to and from intelliHR there’s no guarantee that all systems store dates as UTC, or that all systems reference daylight saving offsets or just standard offsets.
One of the biggest challenges is when another system does not store date-times, but only dates. This happens infrequently but proposes a significant challenge for integrations because it’s unclear what date should be sent to that system. In our earlier example of an employee commencing on the 1st of May in Australia, should we be sending the 1st of May to payroll or the 31st of April? And what happens when daylight saving time kicks in and London temporarily becomes UTC+1:00? Do both systems reference the daylight saving change or does only one? Maybe neither?
Best Practice
If you have an integration to or from intelliHR, or are considering building one, we’ve compiled a list of suggestions to help deliver the best results for your date-times.
✅Check both systems thoroughly
The first best step is before turning on an integration, double check how each system is expecting to handle date-times, and confirm what transformation or conversion may need to take place between the systems to ensure the correct date-times are sent and consumed.
✅Test with “real” data
One of the biggest challenges with date-times in integrations is testing. Often when we “test” software, our behaviour often deviates from how we’d really be using the software. This can be particularly tricky when testing integrations as once the integration is live, you may begin to experience date-time issues that you did not during testing. And because testing procedures often involve altering behaviour, it can have the effect of seeming to “disappear” when attempting to troubleshoot the problem.
For this reason, we recommend testing using “real” data - often the simplest way is to mirror a real record, altering it’s unique identifier - this allows you to compare a record
✅Dates before and after daylight saving offsets
Another key troubleshooting item is to test with dates that occur before and after daylight saving offsets for relevant time-zones. If the date-time changes on either side, this may indicate one of the systems references daylight saving offsets while the other doesn’t, or even the tool performing the conversion may or may not reference daylight saving time.
This helps anticipate future challenges when daylight saving offsets commence or cease.