Mobile Forensics · Timelines & Analysis · Lesson 1 of 5

Timestamps & Epochs

One raw number, three possible dates. Learn to pick the right one.

Same number, three dates

Open a phone database and you rarely see a friendly date like Oct 7, 2024. You see a plain number, such as 750000000. That number is a timestamp: a count of seconds (or smaller units) since a fixed starting moment called an epoch. To turn it into a date, you have to know which epoch and which unit the app used. Nothing in the number itself tells you.

Three formats come up all the time on phones:

• Unix time counts seconds since 1970-01-01 00:00 UTC. It's used widely on Android and by many apps and servers.
• Unix milliseconds uses the same 1970 start but counts thousandths of a second, so the numbers are about 1,000 times bigger. Android's own clock functions commonly work in milliseconds.
• Apple Cocoa time, also called Mac absolute time, counts seconds since 2001-01-01 00:00 UTC. Apple's frameworks use it, so it shows up a lot in iPhone and Mac databases. To convert it to Unix seconds, add 978,307,200, the number of seconds between the two start dates.

Pick the wrong format and you still get a perfectly valid looking date. That's the danger. A message from last year can quietly turn into one from the 1990s, and a tired examiner may not notice.

A few sanity checks help. Does the date fall inside the phone's lifetime? Does it line up with other events from the same database? Is the number about the right length for the unit? A 13-digit value today is probably milliseconds, a 10-digit one probably seconds. Forensic tools usually decode common fields for you, but you should still be able to check their work by hand.

On the simulated phone, read the raw value as each of the three formats in turn and compare the UTC dates you get. Leave the time zone on UTC for now.

UTC, local time and daylight saving

Once you have the right epoch, there's a second trap: time zones. UTC (Coordinated Universal Time) is the world's reference clock. It never shifts for seasons. Most phone timestamps are stored in UTC, and the phone converts them to local time only when it shows them on screen.

A time zone offset is how far local time sits from UTC. Tokyo is UTC+9 all year. New York is the tricky one. In winter it runs on Eastern Standard Time (EST), UTC-5. In summer it switches to daylight saving time, Eastern Daylight Time (EDT), UTC-4. London does the same thing, UTC+0 in winter and UTC+1 (British Summer Time) in summer. The switch dates differ between countries, and the rules have changed over the years.

So you can't convert with one fixed number per city. You need the offset that applied on that date, in that place. Good tools use a time zone database that knows the history of these rules. A note that just says New York is UTC-5 will be wrong for about eight months of the year.

Daylight saving creates odd moments. In spring, local clocks skip an hour, so some local times never happen. In autumn they repeat an hour, so a local time like 1:30 AM can happen twice. A timestamp stored only as local time, with no offset, can be ambiguous on that night.

Why does this wreck cases? If one source is in UTC and another in local time, and nobody notices, events land an hour or several hours apart. A person can appear to be in two places at once, or an alibi can seem to fail when it doesn't. The fix is simple to say: convert everything to UTC, and write down the offset you used for every local time.

In the lab, the Cocoa reading of the sample was 13:20 UTC on Oct 7, 2024, and New York showed 09:20 AM EDT.