Milliseconds not shown in some timestamps

[mfrade]

Hello, when I issue the command:

./time_decode.py --timestamp "2021-03-12 12:39:37.559"

I was expecting to see the milliseconds part 559 on "Unix Milliseconds" and "Active Directory/LDAP" timestamps, but what I get are several zeros instead:

Unix Milliseconds:              1615552777000
Google Chrome:                  13260026377559000
Active Directory/LDAP dt:       132600263770000000

The "Google Chrome" output is ok, but the other two seem to be inaccurate.

[digitalsleuth]

Thanks for pointing that out @mfrade. I'll look into it and get back to you!

[digitalsleuth]

@mfrade This should fix the issue you identified. Give it a shot and let me know if there are any other issues!

[mfrade]

Hello @digitalsleuth, thank you for your time, I love your script and I want to make it my default tool for timestamps.

Regarding the fix, the decimal part with up to 3 digits is ok, but it seems there are some rounding issues on the "Active Directory/LDAP dt" timestamp if I insert more than 3 digits:

./time_decode.py --timestamp "2021-03-12 12:39:37.9945"
Active Directory/LDAP dt:       132600263779944992

it shows 9944992 instead of 9945000

[digitalsleuth]

Interesting indeed. I'll look at that as well. BTW you can also install the tool using pip as well instead of just using the script: python3 -m pip install time-decode.

Once I review this rounding issue I'll get back to you with the results!

[digitalsleuth]

@mfrade This issue should be fixed now, and thanks to your pointing it out, I also pro-actively corrected the same issue on the --guess and --active conversion as well. Give it a shot and let me know if this works for you, then I'll close this issue!

[mfrade]

@digitalsleuth these are another edge cases, so I'm sorry if I'm being too picky.

In this case I understand the round up for Google Chrome from 7 to 8 in the last position, but not the rund down to 0 for the Active Directory/LDAP:

time_decode.py --timestamp "2021-03-12 12:39:37.9945777"

Google Chrome:                  13260026377994578
Active Directory/LDAP dt:       132600263779945770

But even for Google Chrome, the rounding is not consistent. If the same rules apply from the 1st case, the last digit should be 5:

time_decode --timestamp "2021-03-12 12:39:37.9945746"

Google Chrome:                  13260026377994574
Active Directory/LDAP dt:       132600263779945740

But for the last digit of Active Directory/LDAP it should be 6.

Would it be possible to just truncate the decimal part and do all the calculations with 2021-03-12 12:39:37 and then at the end add the .99457777 in the right position? I think this way you could avoid some binary to decimal rounding errors.

[digitalsleuth]

Not being picky at all! Let me take a look at those, and let me know if you see anything else while you're poking around!

[digitalsleuth]

So, part of the problem is the dateutil parser only parses up to 6 digits for a timestamp (down to microseconds, 10-6) and most system clocks don't support nanoseconds (10-9). Since there's a seventh digit in your provided timestamp, that's why the 7 isn't parsed correctly.

Still looking into a better solution. Technically your solution would work, but I'm looking to find a more systematically accurate solution which follows either the math or the basis of the timestamp itself.

[digitalsleuth]

@mfrade I believe this should solve the issues you identified. Give it a shot, and let me know!

[mfrade]

@digitalsleuth it's perfect now. Thank you.