Apple Power Log timestamps continue to be a point of confusion; and it’s easy to see why.

I admit that several years ago I fell for the same confusion while trying to validate a power log record. Essentially, a Device Event that was pulled from the CurrentPowerLog.PLSQL database was important to my case and I was trying to validate the time that had been presented. I went to the source database as I normally would, but the timestamp I was interested in was no-where to be found.

In 2022, My friend and ex-colleague Mike Williamson, along with Sab Strong, did a video about the “Monotonic Timestamp” which I recommend viewing (https://youtu.be/PwzKq1K0bkM?si=NdnmLBBva-Quqaln).

But 3 years later, this is still causing confusion so I’ll take a stab at it too and see if I can add some additional clarity, understanding or information.

The Details

iOS has a series of databases related to Power activities on the device. These databases record information such as Battery Level, Usage, Button Presses, Power Cycles, Battey state etc.

All of these databases start as a database called CurrentPowerLog.PLSQL which is the current file being used. After several days, the file is compressed and saved under a new name related to date of the data it contains. Eg. powerlog_2024-12-08_15DAA1E8.PLSQL.gz
The PowerLog databases are unique in that they record datetime information differently to every other database on an iOS device.

Databases such as those related to Health, Locations, Messages and Calls etc. all work from the same system clock. While they may record the data in a different way, such as seconds or nanoseconds from 1st January 2001, it fundamentally originates from the same clock, which is the same time that is displayed on screen to the user. This means that all activity can be sequentially ordered even if the time was set incorrectly.

The PowerLog databases however utilize what is called a “Monotonic clock”. This is essentially a counter that progresses forward at a constant rate and is unaffected by time changes caused by user activity such as manually adjusting the time, or system activity such as applying a Daylight Savings offset.

Disruptions such as complete power loss/battery drain can cause the monotonic clock to behave in unexpected ways, affecting the counter as the counter function is reliant upon sufficient power (or battery charge) to work as expected.

Think about a regular digital clock that you could buy. When it’s brand new, you set the appropriate time. But gradually, the time on that clock begins to drift. After a year, that clock may no longer be the correct time and require you to set it again. This is essentially what is happening to the monotonic clock and iOS is constantly making synchronisations against the network time.

As an example of how this data works, this is a partial record from the PLBATTERYAGENT_EVENTBACKWARD_BATTERY table of CurrentPowerLog.PLSQL

The “timestamp” field appears to be a UNIX timestamp (number of seconds since Midnight on 1st Jan 1970) and can be converted to a human readable date by adding 1724473913.3173292 seconds to midnight on 1st January 1970. This is equal to 24th August 2024 at 04:31:53 (UTC).

As can be seen in the “Location” section of this record, highlighted in green, there is another table being used to populate the data. This is the PLSTORAGEOPERATOR_EVENTFORWARD_TIMEOFFSET table.

To make sense of the timestamp values in the PLBATTERYAGENT_EVENTBACKWARD_BATTERY table, they require offsetting against a value from the PLSTORAGEOPERATOR_EVENTFORWARD_TIMEOFFSET table.

These records can be described as “check-ins” where the system records the time according to the monotonic clock, and the delta between the monotonic clock and the time according to other sources such as the baseband and system clock.

The offset record referred by Axiom is record 70 which is shown below:

The “timestamp” field here is the value of the monotonic clock at the time of the “Check-in” and is not used other than to help identify which offset record is required for the next step of the calculation.

The timestamp value from the PLBATTERYAGENT_EVENTBACKWARD_BATTERY table needs offsetting against the values presented in the baseband and system fields by adding the timestamp value from the record of interest to the Baseband and System values from the PLSTORAGEOPERATOR_EVENTFORWARD_TIMEOFFSET table.

These values can be seen to be the same timestamps provided by Axiom.

Test 1

While a test device was showing the correct time/date, the flashlight was used at exactly 09:56:00 on 28th December 2024 for 30 seconds.

This resulted in the creation of 2 records within the PLCAMERAAGENT_EVENTFORWARD_TORCH table of CurrentPowerLog with a timestamp of 1734095910.699675 and 1734095940.9988012.

When treated as a UNIX timestamp, these values equal times on 13th December 2024, weeks before when the flashlight activity actually occurred.

The PLSTORAGEOPERATOR_EVENTFORWARD_TIMEOFFSET  table was also updated with a new record which showed:

The selection of the Offset record is based on a comparison between the “timestamp” field in the table of interest (in this case the PLCAMERAAGENT_EVENTFORWARD_TORCH table) and the timestamp field in the PLSTORAGEOPERATOR_EVENTFORWARD_TIMEOFFSET table.

From my testing, the selected timestamp in the Offset table should be as close as possible to the record being investigated without being higher (if possible).

For example, the screenshot above shows a single record from an OFFSET table. But the OFFSET table actually contains many more records, for example;

Each of the records in the OFFSET table requires comparing to the timestamp of interest from the TORCH table. This involves identifying which timestamp is highest of the two. The highest value is highlighted in green.

In this case, the closest value without going over is record ID 871. As such, the Offset value used is the value from the System field of row 871 as highlighted below.

The TORCH timestamp and the System Offset are added together as explained above.

Torch.Timestamp + Offset.System = Timestamp
1734095910.699675 + 1309054.919729948 = 1735404965.3135737541 = 28 Dec 2024 09:56:05 (UTC -7:00)
1734095940.9988012 + 1309054.919729948 = 1735404995.6126999541 = 28 Dec 2024 09:56:35 (UTC -7:00)

This means that we have:
Torch On at 28 Dec 2024 09:56:05 (UTC -7:00)
Torch Off at 28 Dec 2024 09:56:35 (UTC -7:00)

These results are within 5 seconds of the actual time of the flashlight event. Note that this 5 second discrepancy appears with the flashlight every time but is not present on other items that I’ve seen such as Button presses.

Test 2

The device date & time setting was then manually set to 28th November 2024 at 6am (UTC-7).

When the device shows 06:19:00, the flashlight was used again for 30 seconds.

Note that the correct time was 10:36:05 on 28th December 2024. This means that the second test occurred 40mins and 5 seconds after the first test (which you may recall was done at 09:56:00.

This test resulted in 2 records being written to the database, as expected.

When treated as UNIX timestamps, the values show:

Despite the clock on the device being set back by over one month, the values shown here are still showing 13th December 2024.

When compared to the previous records created when the device was showing the correct time it can be seen that there is a ~40-minute difference between the records which is the actual difference between when the tests were conducted.

A few new records had appeared in the Offset table, most notably a record with a negative value.

A few new records had appeared in the Offset table, most notably a record with a negative value.

Again, applying the logic described above;
1734098314.841299 + -1298370.4157130718 = 1732799944.4255859282= 28 Nov 2024 06:19:04 (UTC -7:00)
1734098346.215589 + -1298370.4157130718 = 1732799975.7998759282 = 28 Nov 2024 06:19:35 (UTC -7:00)

Again, performing this calculation resulted in a timestamp this can be seen to be within a few seconds of the time showing on the device when the flashlight was used.

Wrapping Up

The “timestamp” values provided in the CurrentPowerLog tables should not be confused as actual timestamps and require offsetting against other values in the database in order to calculate the actual time of an event.
Forensic tools should be taking this difference into account and Axiom takes the additional step to provide the 3 timestamps within its tool, though this should only be used to aid validation and does not mean that all 3 timestamps hold any relevance.