Considering Time Zones when Processing ESI

Just this week, we had a client request to process data in a specific time zone.  

While there are situations where this makes sense, there are significant benefits to normalizing the dates and times to Coordinated Universal Time (UTC). 

This client was unaware of those benefits and unaware of the potential issues with processing ESI in a specific time zone. It was a great opportunity for us to help them learn something that can have a valuable impact on review and production in their current and future matters. I want to share with you what I shared with them:

To start with, it is helpful to know that for the most part, computers store information using Coordinated Universal Time (UTC), which is the primary time standard by which the world regulates clocks and time.  The Sedona Conference Glossary defines UTC as such:

Coordinated Universal Time (UTC) a high precision atomic time standard with uniform seconds defined by International Time and leap seconds announced at regular intervals to compensate for the Earth's slowing rotation and other discrepancies. Leap second allow UTC to closely track Universal Time, a time standard based not on the uniform passage of seconds, but on the Earth's angular rotation. Time zones around the world are expressed as positive or negative offsets from UTC. Local time is UTC plus the time zone offset for that location, plus an offset (typically +1) for daylight savings, if in effect.

While computer systems store date and time information in UTC format, the applications that you use daily rely on the regional settings on your system to convert that time into your local time zone when you  access and view the data.  For example, if you are on Pacific time and open an email (in Outlook) sent to you at 11 am Eastern time, it will show the email as being sent at 8 am.  That is because the time is translated to Pacific time. Conversely, if you respond at  8:15am Pacific time, your recipient on the East Coast will see it as being sent at 11:15am.  

Consider this: an Outlook calendar appointment for 5:00 PM April 10 made in San Francisco and sent to a colleague in Singapore would show up on their  calendar as a Wednesday April 11 at 8:00 AM.  After normalizing to UTC, both appointments would appear as Wednesday April 11, 00:00:00.  Without this standardization, an e-mail response may appear to have been created before the original  e-mail. Without normalization, it can be challenging to determine timelines of communication people and this can have a negative impact on the review and the productions.

Another challenge is related to deduplication, which relies, in part, on date and time information. Consider the outcome of processing two Custodians' ESI in their local time zones. If both custodians have a copy of the calendar item mentioned above, the copies will not be identified as duplicates. Adding to this complication is the fact that Daylight Savings Time is not recognized in all states and countries.  

So now you have multiple copies of the same document needing to be reviewed because they can not be deduplicated, you can not sort information chronologically and you may end up processing in a time zone different from opposing counsel.  

As you can see, time zones present an interesting challenge for electronic discovery.   Because of the complexities involved in tracking and managing time zone information in a matter, it is common practice to normalize the entire document collection to a standard time zone, such as UTC. 

Whatever you do, make sure you discuss it with the other side so that you are all in agreement on how you be processing and producing your ESI.