Font Size: Increase | Decrease

“We have a big problem with your software, Debra exclaimed at the beginning of our telephone conference, hardly pausing to take a breath after a quick “Hello. She was clearly upset and you could feel that the other lawyers and legal professionals on the call shared her concern.

“What’s going on? I responded as a flash of adrenaline started coursing through my veins. You always hate these kinds of calls but they are a necessary part of this business.

“Something is really screwed up with the times on these emails, she continued, hardly waiting for my question. “When I open up this Outlook email, it shows that it was sent on Tuesday at 9:23 a.m. Yet, when I open the HTML preview version on your system it shows that it was sent at 7:23 a.m. And, to make matters worse, we found a copy of the same email that had been converted to TIFF by our production company. It shows a sent time of 1:23 p.m. Every time is different and my attorneys have lost faith in your system. The same email comes out with radically different times. They are ready to pull the plug.

“Don’t do that, I responded, trying to get my bearings. “Let’s take a minute to nail down the facts and see if we can figure out what is going on. I sensed I had managed to buy about 5 minutes of time to get the train back on the track.

“You are on the East coast, I started. “And when you opened that Outlook email in native format it shows a sent time of 9:23, right? “Yes.

“Now, when you open a preview version of that email in html on our system it shows 7:23, right? “That’s right.

“Then, I think I can explain that one pretty easily, I continued. Times in an Outlook message are dynamic rather than static. It keeps time internally using the Universal Time Coordinates (UTC) which is also called GMT for Greenwich Mean Time. That is London time essentially.

“When you open an Outlook message, the system converts GMT time to the local time on your computer or your network server. Thus, each time you open an Outlook message, your system converts the time fields (e.g. sent, received, accessed) to local time. And, when you opened that email message, it told you it was sent at 9:23 Eastern Time, which was correct in a manner of speaking.

“Well, what about when I open it on your system, she responded. “It shows that it was sent at 7:23 a.m. That is two hours off. You system is changing the time.

“Not really, I responded. “When you open an email on our system, Outlook is doing the same thing it does on your system. Specifically, it is adjusting the time from UTC to the time on our local servers. Since we are on Mountain time, the sent date shows as being two hours earlier than Eastern time. That’s why it shows a sent time of 7:23 a.m. We aren’t changing anything, Outlook is.

“So, you are saying that both times are right and your system isn’t breaking anything? Debra said with a touch of hesitancy not ready to accept my crazy explanation. “Then what about the fact that the production copy has a third time on it? That has to be a mistake, she asserted.

“Well no, I continued. “Not if my assumption is correct.

“Your production company may have chosen to produce all of the files using UTC times, which is pretty common in the industry, I said. “If you do the math I think you will find that UTC is +5 hours off Eastern Time at this time of year. That would mean 1:23 p.m. is correct for a sent date expressed in UTC.

I could see I was losing the crowd at this point but we had hit on one of the trickier issues electronic discovery processing. We all grew up thinking of time as a constant. We meet at 9, we have lunch at noon, we go home at 6. All of this is simple and straightforward, isn’t it?

Not in the world of email, unfortunately. When you send me an email from New York City, it may show a sent time of 2:30 p.m. When I receive it on my system, however, the sent time is magically converted to 12:30, to adjust for Mountain time, which is where I am when I receive it. My reply goes out at 12:35 Mountain Time but you show it as received at 2:35 p.m. That is because you received it on Eastern time.

It gets trickier very quickly. Have you ever seen an email string where it looks as if the person responded to the thread before receiving it? This happens all the time. Take this example:

1. Joe sends an email from the East Coast at 12:15 p.m.
2. Sheryl receives it at 9:15 a.m. and responds at 9:17 a.m.
3. Joe receives it at 12:17 p.m. and replies with a cc to Frank in London.
4. Frank receives it at 5:17 p.m. and replies at 5:19 p.m. to both Joe and Sheryl.
5. Sheryl receives Frank’s reply at 9: 20 a.m. and sends a further response to Joe and Frank at 9:25 a.m.
6. Joe receives the further response at 12:25 p.m. Frank receives it at 5:25 p.m.

If you looked at the email body from that last response by Sheryl, you would see a crazy mix of times. Literally it would seem as if people were responding before messages were sent.

This is because Outlook doesn’t not place a time zone stamp on the “Sent date that is stamped in an email body. All it does is give you the local time sent. When you look through the different messages tracked in the body of the email, time stamps can be all over the place with no obvious way to match them up. This can drive you crazy if you are trying to build a time line of key events for trial. Unless you know where the sender was when he or she sent an email, you don’t know what time they actually sent the email.

What Can We Do About This Problem?

Unfortunately there isn’t a simple answer to this problem. My first reaction in thinking about this problem was simple: Why don’t we always show emails in their local time—the time zone in which they were created—when we display or convert them into an image format (PDF or TIFF)?

At first blush, that would seem to make sense. Let’s say Jane sent an email from Atlanta at 9 a.m. on Monday to Joe in Sydney. Following our logic, we would use Eastern Time for the day and time sent.

If Joe responds a half hour later, the email would show that he sent it at 2 a.m. on Tuesday morning, having received it at 1 a.m. that morning.

This gets confusing quickly when we note that Jane received the response (using her local time) fully 11 hours before it was sent and on the day before. Our simple solution of showing all emails (and other documents) in local time unravels quickly when we start trying to create a master timeline of email transmissions and other events.

The second option, and one often used for productions, is to convert all time-based documents to UTC (GMT or Zulu, whatever you want to call it). That would put London at the center of the universe; some think it is there already.

The advantage of this approach is that all email and other time-based documents (Word, Excel, PowerPoint) would flow in a consistent fashion. Using the example above with Jane and Joe, the email traffic would look like this:

• Jane sends an email to Joe at 1 p.m. on Monday.
• Joe receives the email at 1:02 p.m. on Monday.
• Joe responds to Jane at 2 p.m. on Monday.
• Jane receives the email at 2 p.m. on Monday.

This makes things quite easy. Taking this approach we could rationalize timing for email sent from anywhere in the world. You could always follow an email thread from one message to another without becoming confused about what came when.

As good as this sounds, it would really confuse our American based lawyers. If all U.S. based email in discovery was converted to UTC (essentially adding 5 to 8 hours depending on the original time zone) things could get confusing as well. Imagine presenting a witness with a killer email and asking:

“Didn’t you send an email to my client at 3:13 a.m. on Tuesday the 19 th of July offering to rescind the contract?

“No, I was asleep at that time. I did send something earlier that day.

Try explaining that one to your partner working the case. “Your system changed all the times on my client’s emails? “Well yes, but there was a good reason. Indeed, try explaining that to a government agency bent on finding wrongdoing by your client. You better hope they are time zone savvy.

A third option is to display the local time zone for all emails right in the message itself. Thus, if Jane sent an email at 9 a.m. Eastern time, why not display the local time zone along with the numerical time and date figures? This seems like a good idea to me but most litigation support software doesn’t support it.

There is also the issue of tampering with evidence. If we start adding information or labels to original evidence, are we risking trouble with the courts or the receiving authorities? I wouldn’t think so if the labeling was clear but I don’t think this approach has ever been reviewed.

Ultimately, after looking at different options we decided to let the client decide which time zone they want to use for each job. Thus, if the client wanted to use Eastern Standard for one custodian we would convert times based on that choice. If they wanted to use Pacific Standard for another custodian, perhaps someone based in Los Angeles, we would process that batch using Pacific. Or, we could process all of the jobs in a single time zone, whether that is Eastern or UTC. Since there is not easy answer to the problem we felt the best course was to opt for flexibility.

We do this through mathematical calculations made at the time of processing. The computer simply takes the time of the message, which is always expressed in UTC, and converts it to the desired time zone. That way the client isn’t forced to use Mountain Time, which is the setting on our servers. It doesn’t solve all the issues but it was the best we could come up with to address this tricky issue.

Have you had similar troubles with time zones? Let me know how you handled it or think it should be handled. I will include the best responses in my next FireWire column.