Posted on: February 24, 2016in Blog
UTC, GMT, ESI and eDiscovery: It's About Time
This post explains the UTC time standard, how it differs from GMT, and why it is best practice to process and produce ESI in UTC for eDiscovery.
As the world continues to mature into a global economy, the likelihood of eDiscovery spanning multiple time zones becomes more likely than ever before. Preparing ESI (Electronically Stored Information) for review and production in UTC will avoid the potential negative ramification of processing ESI in a local time zone that may lead to defensibility and usability issues later in the case.
What is Coordinated Universal Time (UTC)?
UTC (Coordinated Universal Time) is the international agreed-to standard by which the world regulates clocks and time. Think of UTC as the “baseline” or “true north” when it comes to standardized time.
Learn how improperly handling metadata in litigation can impact your case by downloading this white paper.
A local time zone is a region on Earth with a uniform time for legal, commercial, and social purposes. Since it is more convenient to keep the same time in areas of close commercial or domestic communication, time zones tend to follow the boundaries of countries and their subdivisions. There are 24 major standardized local time zones in the world.
As businesses expand to worldwide communication, the need for the universally accepted standard of time, UTC, has increased. A transaction may occur across multiple time zones, and keeping track of the accurate time is confusing for all parties involved. To solve this issue, computer servers, email systems, online services and other computer-based systems are based on the UTC standard. The Network Time Protocol, designed to synchronize the clocks of computers over the Internet, also encodes times using the UTC system. All local time zones are encoded in ESI as an offset from the UTC time standard.
How does UTC work?
Coordinated Universal Time (UTC) launches from the Prime Meridian, the 0 degree geographical line of longitude that slices through Europe, West Africa and the South Pacific, dividing east from west around the Earth. To calculate the UTC standard time for a particular location, hours are added or subtracted from either side of the Prime Meridian line. Countries east of the dividing line add one hour for each local time zone crossed. For instance, the local time zone for our recently announced offices in China, is the China Standard Time zone (CST) which is UTC+8. There are eight local time zones east of the Prime Meridian to China. For time zones going west, hours are subtracted for each time zone from Prime Meridian. For example, the Eastern Standard time zone in the US is UTC-5. The difference shows the local time zone in China is 13 hours ahead of the US East Coast.
Attention needs to be paid when calculating local time zones. Some higher latitude countries such as the United States use daylight savings time for part of the year, typically by changing clocks by an hour. For example, the Eastern Time zone is UTC-5 for Eastern Standard Time (EST) in the fall/winter and UTC-4 for Eastern Daylight Time (EDT) in the spring/summer.
Most local time zones are offset from the UTC standard by a whole number of hours (UTC−12 to UTC+14), but a few are offset by 30 or 45 minutes (for example, Nepal Standard Time is UTC +05:45).
Crossing multiple time zones may also affect the actual date of communication or business. On the direct opposite side of the Earth from the Prime Meridian is the International Date Line. At 180 degrees longitude, the International Date Line wiggles its way through the Pacific Ocean, setting the standard for the world’s international date. As you pass the International Date Line, you either add a day (going west), or subtract a day (going east). A transaction occurring today in the US is happening tomorrow in China, an important detail to be included in ESI along with the UTC standard.
So, what time is it in your local time zone? What day of the week is it? Your answer depends on where you are on the planet and what time of year it is (assuming you’re in a location that observes daylight savings time). Fortunately the UTC provides a definitive standard that allows everyone, regardless of location, to know exactly what time it is.
Difference Between UTC and GMT
Often used interchangeably, UTC and GMT (Greenwich Mean Time) are slightly different. GMT is a local time zone where UTC is an international time standard. Based on the Prime Meridian, GMT was established as a local time zone at Greenwich, United Kingdom, in 1886 (long before computers and international time standards were concepts). UTC is also based on the Prime Meridian, which causes some to equate UTC with GMT. However, more than a local time zone, UTC is the standard for coordinating time worldwide, just as the Prime Meridian is the standard for east/west longitude.
It is important to keep in mind: UTC is a universal time standard and not a local time zone.
UTC is notably more specific and precise than GMT. For example, UTC is always a 24-hour expression whereas GMT is expressed in 12-hour expression (a.m. or p.m.). GMT is UTC (+/- 0). Said another way, the local GMT time zone is the UTC standard with zero offset. UTC also accounts for sub second corrections, which is why it is implemented as the international time standard for computer-based systems. Most all timekeeping devices use the UTC 24-hour time standard based on highly precise atomic clocks. The hours, minutes, and seconds that UTC expresses are kept close to the mean solar time at the Earth's Prime Meridian.
It is important to keep in mind: UTC is a universal time standard and not a local time zone.
All Parties Should Agree to the Same Time Zone Early in eDiscovery
Parties rarely discuss and agree to a local time zone standard upfront so defaulting to processing ESI in UTC is the safest and most defensible decision. Problems can arise when one side decides on their own to review/produce ESI in PST (Pacific Standard Time) and the other side decides on their own to review/produce ESI in EST (Eastern Standard Time). This would result in a three-hour discrepancy in the produced metadata, which can lead to confusion and may open the door to unnecessary discovery protocol disputes.
Some document review platforms provide a “local time zone offset” feature that will display the date and time in the selected local time zone during the review process. This enables the extracted metadata to remain in UTC, as it was originally encoded in the native file, as well as provides review teams a more efficient means to switch between multiple time zones during review.
Why You Should Process and Produce ESI for eDiscovery in UTC
1. Avoid confusion and disputes.
Altering extracted metadata could result in confusion and discovery disputes. Processing email in a time zone other than UTC changes the extracted metadata for the email by altering the base time of the email with the local time zone offset. While the metadata in the native file is not altered, if a question arose regarding exactly when the document was sent or received based on the extracted metadata, that offset could be questioned. Processing in UTC avoids that unnecessary confusion altogether.
2. Easier to calculate the local time across multiple time zones.
When using local time zones, changing the base time zone will make it more difficult for parties to authenticate the actual date/time of a document. If ESI is processed in something other than UTC and the parties want to determine the local time for a different time zone, the parties would need to know what time zone the data was processed in, choose the correct offset to get back to UTC and then make the offset adjustment from UTC to the other time zone. In today’s connected world, processing and preserving data in UTC makes these local time zone calculations much simpler.
3. More defensible to process ESI in UTC.
Recording times in UTC establishes solid data. Processing ESI in a different zone other than UTC can open the door for the opposing party to question your eDiscovery protocol. It also may result in having to reproduce if the local time zone is not acceptable with the opposition.
Two Possible Exceptions*
- UTC may not be required in a matter where all the evidence is in a single time zone and processed/normalized to that local time zone.
- If a party has already processed ESI in a different time zone than UTC, they would (most likely) want to maintain the original time zone for further processing and production.
*Both of these exceptions would require all parties to be aware of the time zone shift during processing should date/time authentication come into question. Parties can always go back to the original source ESI that contains the UTC encoding if time zone questions arise.
Simplify the eDiscovery Process
There is no reason to make eDiscovery more challenging than it already is or to take unnecessary risks in defensibility that could open the door to discovery disputes. Follow best practice and keep ESI in UTC throughout all phases of discovery and production.
- 5 Things Every Attorney Should Know about eDiscovery Productions
- A Quick Guide to eDiscovery Production Formatting Options
- ESI Processing Simplified - What Every Legal Team Should Know
- PDF Files Can Wreak Havoc in ESI Processing, Review and Production
D4 Weekly eDiscovery Outlook
Power your eDiscovery intellect with our weekly newsletter.
Posted October 20, 2017
How to Use the eDiscovery PST Export Tool in Office 365 E3
Posted October 12, 2017
Recent eDiscovery Cases for Mobile Phones and Social Media
Posted October 05, 2017
Raising Objections to the Format of ESI Productions: Do it Early and Do it Clearly
Posted September 27, 2017
5 Reasons eDiscovery Alternative Fee Models Make Sense for You
Posted September 22, 2017
Why it's Crucial to Have a Corporate Mobile Device Policy
Posted September 13, 2017
Taking a Team Approach to eDiscovery Projects
Posted September 06, 2017
3 Document Review Tips from eDiscovery Project Management Experts
Posted August 31, 2017
China’s VPN Crackdown Weighs on Foreign Companies There
Posted August 30, 2017
A Simple Approach to Managing Healthcare Data and eDiscovery
Posted August 23, 2017
Why New Healthcare Technology Needs to Keep eDiscovery in Mind