Interpreter - timestamps

[RuneN007]

Hi,

I think it would have been very good if you include a showing timestamps in human readable format in the Interpreter (or another pane)

Maybe a checkbox for UTC, if selected timestamps are shown in UTC+0, if not the timestamps are shown in localtime using the timezone of the computer.

• NTFS => 100 Nano seconds intervals since 1.1.1601 (UTC+0)
• FAT Date => See http://www.tavi.co.uk/phobos/fat.html in the section for File Time and File Date. Local time of the computer that saved it.
• Unix epoch => Seconds since 1.1.1970 (UTC+0)
• HFS+ => Seconds since 1.1.1904 (UTC+0)
• APFS => Nanoseconds since 1.1.1970 (UTC+0)

Regards

Rune

[RuneN007]

The hard thing here is to make sure the conversion is supported by all OS.

Example function:

const char* DataInterpreter::getUnixDate( int64_t seconds ){
    time_t sec = seconds;
    struct tm * timeinfo;
    char * theTime = NULL;
    if(seconds != sec ) // conversion to time_t lost data...
        return "Not valid";
    #ifdef __WXMSW__
    wxDateTime aDate(sec);
    #endif
    if(m_check_UTC->GetValue() ){
        #ifdef __WXMSW__ 
        return aDate.Format("%c", wxDateTime::UTC).c_str(); // Uses UTC
        #else
        theTime = asctime(gmtime(&sec));
        if(strlen(theTime) > 0){
            theTime[strlen(theTime)-1] = '\0';
            return theTime;  // Copy of string
        }
        else
            return "Not Valid";
       #endif
    }else{
        #ifdef __WXMSW__
        return aDate.Format("%c", wxDateTime::Local).c_str(); // Uses local time
        #else
        theTime = asctime(localtime(&sec));
        if(strlen(theTime) > 0){
            theTime[strlen(theTime)-1] = '\0';
            return theTime;  // Copy of string
        }
        else
            return "Not Valid";
        #endif
    }
    return "Not valid";
}

[EUA]

Well... for supporting all those formats, we definitely need a time machine. Calling Dr. Emmett Brown

[EUA]

Hi Rune, I made some progress, You can look by adding optional flag while compiling... make OPTFLAGS="-DHAVE_A_TIME_MACHINE"

I have some questions, Unix Epoch time is 64 bit and 32 bit on some system, so we need to allow both?

Also FAT time, do they always together? If it is, than why don't we handle them together as a single 32bit FATDate?

<------- 0x19 --------> <------- 0x18 --------><------- 0x17 --------> <------- 0x16 -------->
15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
y  y  y  y  y  y  y  m  m  m  m  d  d  d  d  d   h  h  h  h  h  m  m  m  m  m  m  x  x  x  x  x

I put an UTC with a counter allow user change from +12 to -12. Also put a local time checkbox for those doesn't know their local timezone. Those are not working due no Flux Capacitor here, yet. I ordered one. Will come after release.

Doesn't it need to be a GMT instead of UTC? Not sure about it. Proper to say is, GMT+3, not UTC+3, doesn't it?

[RuneN007]

We can support both 32 and 64 bit for unix epoch. However, current file systems implement this differently.

FAT date is accurate for FAT12,16 and 32. But not the FAT dates in ExFAT, since the also saves the UTC offset in another field.

I think you are fine using UTC or GMT.

Med vennlig hilsen

Rune Nordvik

16. des. 2019 kl. 02:56 skrev Erdem U. Altinyurt [email protected]:



Hi Rune, I made some progress, You can look by adding optional flag while compiling... make OPTFLAGS="-DHAVE_A_TIME_MACHINE"

I have some questions, Unix Epoch time is 64 bit and 32 bit on some system, so we need to allow both?

Also FAT time, do they always together? If it is, than why don't we handle them together as a single 32bit FATDate?

<------- 0x19 --------> <------- 0x18 --------><------- 0x17 --------> <------- 0x16 --------> 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 y y y y y y y m m m m d d d d d h h h h h m m m m m m x x x x x

I put an UTC with a counter allow user change from +12 to -12. Also put a local time checkbox for those doesn't know their local timezone. Those are not working due no Flux Capacitor here, yet. I ordered one. Will come after release.

Doesn't it need to be a GMT instead of UTC? Not sure about it. Proper to say is, GMT+3, not UTC+3, doesn't it?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/EUA/wxHexEditor/issues/85?email_source=notifications&email_token=AGCA7BOGVQHBYLN73RDOFEDQY3N43A5CNFSM4EIVL43KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG5JB5A#issuecomment-565874932, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGCA7BNR3SZSR2EWLWACDJ3QY3N43ANCNFSM4EIVL43A.

[EUA]

I think if we don't need to include "accurate exFAT timing" since it's ... weird format. Different offsets for creation and for and last modified areas... If you put cursor at to creation time, you are away 14 byte to its UTC offset. 11 for last modified and 8 for last accessed.

We need to put 3 different time for accurate exFAT reporting. Yes we can but does it useful for anyone? Since FAT give really satisfactory result and users could adjust their UTC, I think it's not worth to work on it and add 3 time formats just for exFAT.

[RuneN007]

Yes, you are correct. ExFAT makes this difficult, which also may be the reason why other tools do not support it.

However, a user may use the FAT time and wrongly interpret ExFAT time. In order to interpret ExFAT time, you need to know the start of the file directory entry.

Here is more info on the directory entry: http://www.ntfs.com/exfat-file-directory-entry.htm

Maybe a view that interpret all info from a directory entry, not only time?

[EUA]

you need to know the start of the file directory entry. Do we need? Nope. We can do it without it since relative location of local time is same always(?). Because interpret creation time as FAT + read 14.th byte and add it (of course as time) gives us proper result (discarding the 10ms additions as I write).

The main problem is adding a line for each "ExFat Creation", "ExFat Modification", "ExFat Access" looks like overkill to me. Not hard to do it programmatically... All I need to increase data buffer to 128 bit than we can correctly interpret each exFAT time/date, including 10ms additions. But I don't think if it's useful. Because user also need to aware which time going to interpret, Creation,Modification or Access... I think it make complicate things.

But data Interpretation panel data interpretation is depended to cursor location. User has to put cursor to beginning of the time section that program gonna interpret. We can't make cursor points to "file directory entry" and show things at data interpretation panel. So, do we actually need this? Does it life saver? Well, If you think that, it's a must thing, a killer feature... Than okay. I can make such a thing like that. If user want, could disable exFAT pane also.

Maybe a view that interpret all info from a directory entry, not only time?

You are asking for a custom interpretation panel for this job, like Info Panel but for Cursor locations. It might be a plugin add on does the job. But this is definitely not interpreter panel related thing, just for RAW interpretation. Not for interpreting complex structures.

[EUA]

I add exFAT to FluxCapacitor. 9b6bd5b9c0a5c5ff8a60f07ae916167624a5ba97 You can test it via make OPTFLAGS="-DHAVE_A_TIME_MACHINE -DHAVE_EXFAT_TIME"

[RuneN007]

You are correct about the relative positions. The main problem is to identify which of the ExFAT timestamps the user have his cursor on. If it is possible to test which one, then we need only to show the correct interpretation of the ExFAT time stamp where the user have the cursor including the time zone field. This will make it more intuitive for the user. I do not think any tool do this properly today.

[EUA]

The main problem is to identify which of the ExFAT timestamps the user have his cursor on.

this is completely users problem and not a good idea to solve in data interpreter. Currently, user need to put cursor to first byte of File Creation Time, than wxHexEditor shows all exFAT times. Otherwise there are no proper way to identify cursor location shows what. We can do a bitmasks, which is already done for filter out invalid (OUTATIME) data but this doesn't give us proper results about if it's Mod time, access time or creation time.

[EUA]

Enabled at trunk but having issue with assertions now. I will try to fix it.