Date/time information extracted from e-mails and electronic documents is a major aspect of electronic evidence. In order to interpret and display the extracted timestamps correctly, most digital forensics and e-Discovery software require the end user to specify a time zone. The selected time zone can have numerous effects such as the appearance of timestamps on printed e-mails or whether or not certain documents fall within the relevant time frame during culling. Especially in cases that involve multiple time zones, it is critical to determine how time zones should be handled in order to avoid potential problems down the road.
What are Time Zones?
Due to the shape of the earth and its rotation around the sun, different parts of our planet observe different parts of the day at the same time. Time zones are used to ensure that the same clock time corresponds to the same part of the day throughout the world. Traditionally, all time zones were represented as an offset from the Greenwich Mean Time (GMT). As technology advanced and more accurate time keeping devices became available, Universal Coordinated Time (UTC) emerged as the new international time standard. UTC is a form of atomic time and is regularly modified (leap seconds) in order to account for the irregularities of the earth and sun’s movements.
How Date/Time Values are Stored
Different computer systems and software use different methods to store timestamps. The following are a few examples that we encounter frequently.
1. Ms Outlook Emails
Ms Outlook stores e-mail dates in UTC and displays them in the end user’s local time zone. The example e-mail in Figure 1 was sent on 04/16/2012 at 1:08 PM Pacific Daylight Time (PDT). You can see that Outlook displays the sent date in the local time zone (PDT) while it stores it internally as the PR_CLIENT_SUBMIT_TIME value in UTC. On the other hand, the message header shows the same value in Eastern Daylight Time (EDT) since the server through which the message was sent was in EDT.
2. Ms Office Documents
Most Ms Office documents also store internal document metadata in UTC. For example, the Ms Word document in Figure 2 was created on 4/16/2012 at 1:22 PM (PDT). Looking at the docProps\core.xml file reveals that the internal metadata was stored as “2012-04-16T20:22:00Z”, which is the same as 04/16/2012 8:22 PM (UTC).
3. File Systems
File systems (e.g. FAT32, NTFS etc.) also store valuable date/time information about files. However, the way they store this information varies. For example, NTFS stores timestamps in UTC, as the number of 100 nanoseconds since 1/1/1601 (UTC). On the other hand, FAT file systems store date/time values in local time without a time offset. This means that one would have to know the correct time zone in which a file was created and used in order to determine its actual local date/time. For example, imagine the following scenario:
- File 1: Created in a FAT32 file system on 06/01/2004 at 9:32:15 PM (PDT)
- File 2: Created in an NTFS file system on 06/01/2004 at 9:32:15 PM (PDT)
If both files were viewed today on a computer in EDT, File 1’s creation timestamp would appear as 06/01/2004 9:32:15 PM while File 2’s timestamp would be 06/02/2004 12:32:15 AM. The difference is caused by the fact that FAT32 only stores the date and time without the time offset and even if the file was later viewed in a different time zone such as EDT, its timestamp would not reflect the local time zone in which the file is viewed.
Potential Issues Regarding Time Zones
1. Processing Output
Applications that store timestamps in UTC typically adjust the displayed value depending on the end user’s selected time zone. This means that the same document can produce different output during e-Discovery processing depending on the chosen processing time zone value. For example, the processing output for the test e-mail we mentioned earlier would be as follows:
As seen in Figure 3, the e-mail message was printed with a sent time of 4:08 PM when processed using the Eastern Daylight Time (EDT) zone. While this may not always be an issue, it is important to ensure that legal teams understand that the printed date/time values may or may not be the actual local date/time the e-mail was sent by its author or received by its recipient. In some cases, it may be possible to process e-mails in a way that the actual time offset is displayed in the output (see Figure 4).
Additionally, making sure that the review database always contains fielded information regarding the selected processing time zone and the UTC timestamps for each document would help alleviate this issue.
Most e-mail platforms create cryptographic hash values for e-mails based on a combination of several metadata fields such as sent date, author, e-mail subject etc. While calculating these hash values, e-Discovery software should use UTC timestamps rather than local time. Otherwise, e-mail hashes would be a function of local time and would change depending on the selected time zone. This means that two copies of the same e-mail processed in different time zones would not be treated as duplicates.
3. Date Restrictions
When documents are culled using date restrictions, the selected time zone may determine whether or not a document falls within the relevant date range. For example, imagine an e-mail that was dated 04/30/2009 9:05 PM (PDT). If a date restriction was performed using Eastern Time, this e-mail would not fall into the date range 1/1/2009 – 4/30/2009 since the e-mail’s local date would be interpreted as 5/1/2009 12:05 AM (EDT).
4. Daylight Saving Time
Daylight Saving Time (DST) is the practice of advancing clocks forward by one hour in spring and moving them again backwards in autumn so that afternoons have more day light and mornings have less. The start and end dates of DST have changed several times in the past, making it a challenge to determine the actual local timestamps of documents in the past. For example, in order to determine the correct local timestamp of a file dated 3/12/1991 12:45:31 PM (UTC) that originated from Sweden, one would have to know whether or not DST was in effect at that time in Sweden. The tz database is a valuable resource which contains the history of local time for many representative regions in the world.
We believe that taking the time to ensure that time zones are handled correctly in a project should be at the top of a project manager’s priority list. Briefly, the following key points should be considered:
- Legal teams should decide how time zones should be handled at the onset of each project and communicate their preference to the e-Discovery service provider as part of e-Discovery processing specifications. It is common practice to normalize all times to UTC and capture each custodian’s time offset in cases involving multiple time zones.
- e-Discovery software should normalize document timestamps to UTC while performing de-duplication.
- The time zone used during e-Discovery processing as well as the UTC timestamps of each file should be included as additional fields in the review database.
- Effects of time zones and Daylight Savings Time should be considered while constructing date restrictions.
- Legal teams should be aware of the fact that depending on the chosen time zone, timestamps printed as part of processed documents (e.g. e-mail dates) may or may not reflect the actual local time when the e-mail was sent or received.