The “Perfect Date”

I am watching a walkthrough video of a new-to-me eDiscovery software, and there are so many potential pitfalls for the unwary in each option in the case set-up!  It made me think about dates.  There are several options in typical metadata for “what is the date of this email/document/file,” and particularly in file attachments, they can (a) all be different and (b) create some hazards if you choose to filter or cull your set by the wrong one.

Just in time for Valentine’s Day, Spark brings you: The Perfect Date?

Date Sent

Date Received

Create Date

Date Last Modified

Family Date

First, a note on time zones:  Most platforms will standardize timestamps to a particular time zone if you ask them to when ingesting your data.  That means, if your client is in New York but has an office in Hong Kong, then the “sent/received” times for the HK custodian will be changed to Eastern Time.  Upside:  when you filter for emails sent at a critical time, the HK custodian’s will show up, in chronological order, with the ones from your New Yorkers.  Downside: In isolation, you may look at an email and wonder why your Hong Kong employee was sending it at 3 a.m. their time. 

Back to the Perfect Date. (April 25.)

Scenario:  the relevant date range for my case is January 1, 2015 to May 1, 2021.  The client’s finance group circulates a report every month that is built out of new reports from the accounting system, but copied and pasted into a reader-friendly Excel format that was created in 2008.

Me:  I will cull out any document where the Date Created is before 2015!

Omnicient Narrator:  This was a mistake. 

The parent email may have been Sent June 4, 2018, but the attachment’s Date Created remains October 9, 2008.  The version attached to the email was Modified on June 3, 2018, and its Family Date will (probably) be the date the email was sent, June 4, 2018.  And your software may have assigned it a “Date” based on any one of these other factors, depending on the system.* A standalone version of this report attachment, sitting on the Finance share drive, will share the Date Modified with its sibling attached to the email, but not the same Family Date, and therefore possibly not the same Date.

Worse:  What if your CEO, in an effort to be helpful, sent a year’s worth of these report emails to counsel, attached to a single email, in July 2021?  Now the Family Date of these versions of the report attachments may be July 12, 2021, and outside your date range.  And the parent email, at least, is privileged.  But the reports and their parent emails are within the responsive date range, and they need to be produced in some form.  The reports attached to the CEO’s privileged email have the same hash value as their duplicates elsewhere in the CEO’s inbox, but they are not identical in family metadata.

So what is the Perfect Date to rely on when culling data to within my responsive date range? 

Omnicient Narrator: Do not say “it depends”!

Me:  Probably “Family Date,” as long as your system sets Date Modified as the Family Date for standalone documents.* 

* For example, DISCO defines “Date” for emails as the Send Date, and for all other document types as Last Modified.  The Family Date for standalone non-email files will be the Modified Date.  Relativity can run a script to populate a Family Date for email families based on the Send Date, but does not automatically define one.  Lexbe defines a “Doc Date” (Sent Date for emails, Date Created or Date Last Modified for native files) and a “Master Date” (a Family Date based on Sent Date propagated to attachments; Date Last Modified for standalone files, or Date Created' if Last Modified is not available.