From APFS documentation it is revealed that the new timestamp has a nano second resolution. From my data I can see several timestamps in what appears to be the root directory for a test APFS volume I created. Armed with this information, it was pretty easy to guess the epoch - it is the Unix epoch.
Now 010 can interpret APFS timestamps :)
If you need to read this timestamp in python (and convert to python datetime), the following function will do this:
import datetime
def ConvertApfsTime(ts):
try:
return datetime.datetime(1970,1,1) + datetime.timedelta(microseconds=ts / 1000. )
except:
pass
return None
Update: As noted by Joachim, the timestamp is an int64, and has been corrected in the above code.
ApfsTimeStamp = number of nano-seconds since 1-1-1970
If you like to use the 010 editor for analysis, put the following code in your Inspector.bt or InspectorDates.bt file:
//----------------------------------------------------------------
// ApfsTime
// 64-bit integer, number of nanoseconds since 01/01/1970 00:00:00
typedef int64 ApfsTime <read=ApfsTimeRead, write=ApfsTimeWrite>;
FSeek( pos ); ApfsTime _aft <name="ApfsTimes">;
string ApfsTimeRead( ApfsTime t )
{
// Convert to FILETIME
return FileTimeToString( t/100L + 116444736000000000L );
}
int ApfsTimeWrite( ApfsTime &t, string value )
{
// Convert from FILETIME
FILETIME ft;
int result = StringToFileTime( value, ft );
t = (((int64)ft - 116444736000000000L)*100L);
return result;
}
Now 010 can interpret APFS timestamps :)
 |
| 010 interprets ApfsTimes |
import datetime
def ConvertApfsTime(ts):
try:
return datetime.datetime(1970,1,1) + datetime.timedelta(microseconds=ts / 1000. )
except:
pass
return None
Update: As noted by Joachim, the timestamp is an int64, and has been corrected in the above code.
