You know what daylight saving time changes mean: we’re back with another installment of Zack’s Time Zone Corner! Last time, we talked about basic time zone information and trivia. We’ll have more of that to come in future posts—and I promise a bit of that today if you make it through the article! For today, our focus will be on time zone considerations in eDiscovery since we are an eDiscovery company after all. The fun truly never stops!
How To Pick a Time Zone for Data Processing
Whenever we’re processing data, we have to make a choice about what time zone to use and then keep it consistent for that matter. This is because date and time metadata is always stored in UTC (Coordinated Universal Time). While you often see a different time displayed on your computer, phone, or another electronic device, that’s because it’s converting the time from UTC to the time zone set on the device. The time zone chosen for processing will affect the native, text, metadata, and any images created of the native later in the case so make sure you’re choosing wisely! Here are some of the factors to consider before you pick a time zone for processing.
You may think, “Well we collected the whole computer/phone/PalmPilot so can’t you just take the setting from the device?” In most instances, that would be possible, but it’s usually not what we’d recommend.
Some custodians travel regularly, meaning the time zone settings on those devices could be updating automatically based on location. Additionally, there’s nothing to say that someone needs to have their time zone set based on their location. If a custodian lives in Mountain Time, but the majority of her colleagues/clients are in Eastern Time she might set her computer to Eastern Time to make scheduling easier.
Additionally, most eDiscovery cases involve more than one custodian so if we were to rely on a single custodian’s time zone that can lead to confusion later, especially if other custodians aren’t in that time zone. It’s fairly common for cases to start with only one custodian and then more custodians are identified as the case proceeds. Those new custodians could be in different locations, and you want to be prepared for that.
Opposing Counsel Considerations
Since we’re usually dealing with data from multiple parties, it’s best to coordinate time zone settings with the other side.
Let’s say we have a case involving a dispute between ABC Corp. and Data Incorporated. Sally Docs from ABC Corp. and Donny Data from Data Incorporated were regular email correspondents, and those emails are relevant to the dispute. Reviewing productions from both sides will make a lot more sense if processed in the same time zone so you’re not looking at this:
These appear to be the same email but since ABC Corp. used UTC and Data Incorporated used Eastern Time, they’re not only displaying different times but also different days. It’s best to have an agreement or protocol in place at the beginning of a case to avoid these situations.
So What Should I Use!?
Well that’s up to you! I’m just here to provide you with knowledge to form your own opinions.
No, that doesn’t work? You want recommendations? Fine, we can do that.
For standard/traditional eDiscovery data types (email and eDocs from a computer, network, etc.), we generally recommend using UTC. As mentioned previously, we recommend coordinating with other parties so that all parties are using the same time zone.
Of course, there are caveats which is why this is a general recommendation! If there is existing data which has already been processed in another time zone then it would be best to match that time zone to maintain consistency.
For certain data types such as text messages and other mobile data, it may be best to use a local time zone depending on the processing method. With Contact’s MobileRev processing tool, we usually recommend that a single, local time zone is selected. This is because MobileRev generates records on a daily basis so you’d be more likely to separate specific conversations across different daily records if using a non-local time zone.
Let’s say the custodians are all in Eastern Time, but the data is processed in UTC: all messages after 7:00 p.m. EST or 8:00 p.m. EDT will be in the next day’s record. Additionally, dates are always a key factor when we’re reviewing data, but for mobile data, the time is often more relevant than it may be with email. By using the local time zone, we can make sure it’s clear to reviewers that a text message occurred at 5:00 p.m. and not 10:00 p.m. That 5:00 p.m. “Coffee in the break room?” text message will likely appear much different to the reviewers than a 10:00 p.m. “Coffee in the break room?” text.
What Can I Do to Change Time Zones?
We always have different options to consider based on the specific situation.
Most eDiscovery tools include a time zone offset feature that can change how an email is displayed within the platform. This can be helpful for review purposes, but it won’t change metadata fields, images, or the text itself.
For metadata fields, we can convert them to a different time zone. We’ll just want to be careful not to have mismatching values on the native/image/text and in the metadata.
What to do about the natives themselves? We can produce a time zone field for clarity. We can also look at the specific scenario to determine if it would be feasible to reprocess the data or replace native files.
Empowered with this information, you should be ready to make the best time zone decision for your case and specific data set in the future! Most of the time that will be UTC for email/eDocs or wherever the first few custodians are for your mobile data.
As promised, your reward of time zone trivia! This is posting on St. Patrick’s Day so we wanted some Irish-themed time zone trivia. On St. Patrick’s Day, those of us in the USA are one time zone closer to Irish time than the majority of the year. This is because the USA starts daylight saving time before Europe, and St. Patrick’s Day falls in that in between time.
P.S. – For everyone in Eastern Time, it’s EDT until November 7th!! (or use ET year-round!)