Don’t Trust the Clock: Timestamp Discrepancies in iOS Unified Logs

Disclaimer: The information and analyses presented in this article are the result of personal research and testing. They are provided for informational and educational purposes only. Any commercial use of the contents of this article without prior written permission from the author is strictly prohibited. Users are not authorized to copy, reproduce, transmit, or distribute the contents of this article without permission. The author disclaims any responsibility for the consequences of using the information contained in this article. For permission requests, please contact the author directly.

In digital forensics, timestamps are often considered reliable indicators for reconstructing the sequence of events. However, when examining iOS Unified Logs in the case of a manually modified date and time, certain discrepancies may appear depending on the method of analysis used.

This article documents a situation where a single log entry, identified notably by its ActivityID, displays a different timestamp depending on whether it is viewed live via the macOS Console or extracted from a logarchive for forensic analysis. This raises important considerations regarding the interpretation of timestamps in cases where the device’s time settings may have been altered by the user.

Live Analysis vs Forensic Investigation: Timestamp Discrepancies in the Unified Logs

When I do my research to identify relevant logs and build my articles, I always rely on the macOS Console. It’s a very practical tool for observing logs in real time, and it helps me understand which actions trigger which log entries.

Recently, I was running tests to identify useful logs that appear when a user manually changes the date and time on their iPhone.

On March 23, 2025, I began a test where I manually changed the date and time settings on my device. At first, the system was set to adjust the time automatically. I then disabled that setting and manually rolled the date back to March 6, 2025 (see red rectangle in the image below).

While doing this, I monitored the Unified Logs in real time using the macOS Console. As soon as the change occurred, I observed a log generated by the timed process with the following message:

This log is particularly interesting in the context of a manual date or time change, as it explicitly mentions "TMSetManualTime".

At first glance, everything looked fine: the timestamp of the log matched the new date I manually configured: March 6, 2025.

Forensic Investigation of the unified logs

After finishing my live analysis, I extracted the logs using the standard .logarchive format just as I would in a real forensic investigation to verify my live observations. I searched for the same entries using both the ActivityID and the log message, expecting to find the same events with identical timestamps.

But that’s not what happened (!) and here's what I can observe:

1. Each log is saved twice during the live analysis, but only once in the .logarchive extraction (which actually reduces the noise).

2. In Terminal, ActivityIDs are displayed in hexadecimal format, unlike in the live Console view. For example, the hex code 0x3e8b8 corresponds to the decimal value 256184.

But, despite the logs being "functionally identical" (same process, same content, same ActivityID whichis really important) their timestamps are problematic ! In the logarchive version, the log that previously showed a timestamp of March 6 in the Console now appeared as March 23 ! In other words, it don't reflect the new date I manually configured as it did during the live analysis. It shows the actual date when I performed the change. And that changes everything !

To verify that this wasn’t an exception, I repeated the tests with multiple manual time changes. Looking at logs with a different ActivityID, for example 257261 (or 0x3eced in hex),I observe the same result (see blue rectangle in the images above):

• In live analysis (Console), the log shows a timestamp of February 5, 2025

• In the forensic .logarchive, the log shows March 1, 2025

Again, the timestamps don't match but the result is consistent: the live logs reflected the manually set system time, while the forensic extraction preserves the date/time of the device when the action actually took place.

To dig deeper, I continued the forensic analysis by exporting the logs in JSON format, just to see which timestamp was embedded there…

Once again, the timestamp in the JSON log shows the date of the action itself, not the new date selected by the user.

From an investigative point of view, this is actually a good thing: so far, all timestamps in the forensic analysis are consistent. They reflect the real moment when the manipulation occurs, rather than the altered system time.

Finally, when I open the extracted .logarchive in Console, I see the same pattern:

the timestamps displayed correspond to those from the forensic extraction, not the ones observed during the live analysis.

The timestamp observed during the live analysis only appears in the live view. At no point does it show up in the forensic extraction, which is very reassuring. The logs contained in the .logarchive therefore seem more reliable than those seen in the live analysis.

How to determine the new date in the unified logs?

To conclude this article on a positive note, here is a log that is definitely important when we investigate manual date and time changes.

This log also shows the same timestamp issue, and it shares the same ActivityID as the one discussed earlier in this article (256184), which clearly help us to link them:

Since the image above is quite small, here's the text of the log: "Setting manual time with dictionary {

    TMAbsoluteNanoTime = 762955200000000000;

    TMCommand = TMSetManualTime;

    TMCurrentTime = 762955200;

    TMMachTime = 229906788255;

    TMRTCConversionTimeError = "0.0005004433";

    TMRtcTime = "9579.632711";

}"

This log tells us that on March 23, 2025 at 13:00:27, the user manually changed the date and time of the device. It also allows us to determine the new date that was selected.

In fact, the log contains the variable TMCurrentTime = 762955200, which is a timestamp in Cocoa Core format (the number of seconds since January 1, 2001). And if we convert that value using a timestamp converter, guess what we get? It gives us the exact date and time shown in the Console during the live Analysis (!): March 6, 2025 at 13:00:00 GMT+1.

That brings everything full circle.

Enjoy your Digital Investigations !

Lionel Notari

FAQ – Timestamp Analysis in iOS Unified Logs

Can Unified Logs show different timestamps depending on how they were accessed?

Yes. Live Console views and forensic .logarchive extractions can produce different timestamp values for the same log entry.

Which timestamp should I trust in a forensic context?

The logarchive timestamp is more reliable.

Can I still recover the exact time selected by the user?

Yes! logs may include variables like TMCurrentTime, which can be converted to determine the exact manual time configuration.