eDiscovery Daily Blog

What Time Is It? That is an Important Question When it Comes to Your Document Collection: eDiscovery Best Practices

It may not be game time (hoo!), but the question of what time it really is has a significant effect on how eDiscovery is handled.

Our clients that process their electronically stored information (ESI) with CloudNine’s Discovery Client processing application (shameless plug warning!) generally find the wizard based application for processing and loading data to our review platform easy to use (as of this week, you can now process your data for loading in your own preferred review platform). But, for those few clients who have questions, we get one question WAY more than any other:

Why is the application asking me in which time zone would I like for my dates to be displayed?

Most ESI is stored in UTC (Coordinated Universal Time), which is the primary time standard by which the world regulates clocks and time. That’s not the same as Greenwich Mean Time (GMT), which is actually a time zone, not a time standard like UTC. The user’s operating system uses regional settings on the user’s system to convert the UTC time to the user’s local time zone. In many litigation cases, one of the issues that should be decided up front is the time zone to apply to the produced files. Why is it a big deal? Consider this example:

A multinational corporation has offices from coast to coast and potentially responsive emails are routinely sent between people in New York and Los Angeles offices. If an email is sent from one custodian in the Los Angeles office at 10 PM on June 30, 2013 and is received by another custodian in the New York office at 1 AM on July 1, 2013, and the relevant date range is from July 1, 2013 thru December 31, 2014, then the choice of time zones will determine whether or not that email falls within the relevant date range. Because the time zone is based on the workstation setting, the two employees could actually even be in the same office when the email is sent (if someone is traveling).

As noted in the recently released EDRM Data Processing Standards Guide (which we covered here), if the processing time zone for the case is not standardized across the entire collection, then the email metadata for custodians in the different time zones will be different – because the time (and, possibly, the date, as indicated in the example above) would be different. As a result, two copies of the same email (one in the New York custodian’s email collection and one in the Los Angeles custodian’s email collection), would fail to be de-duplicated. Not to mention that the different time zones would create a convoluted chronology or, as in the example above, a convoluted relevant date range.

As a result, most eDiscovery processing software (including ours) expects you to use a standard time zone for all files in the case. That can be the predominant time zone where the producing party is located – for example, an organization has offices throughout the country, but its headquarters is (along with most of the producing custodians) based in Houston, TX – so you might choose Central Standard Time as the time zone for the case. Or if the producing party is fairly evenly spread out across multiple time zones, you can choose to standardize to UTC.

So, what do you think? Have you had any date disputes in your eDiscovery projects?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine. eDiscovery Daily is made available by CloudNine solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.