Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timestamp format in report.xml drops 0 fraction #206

Open
govcert-ch opened this issue Mar 4, 2019 · 1 comment
Open

Timestamp format in report.xml drops 0 fraction #206

govcert-ch opened this issue Mar 4, 2019 · 1 comment

Comments

@govcert-ch
Copy link

Hi,

This is not really a bug, but I don't think it's planned this way neither. In report.xml, timestamps (startime/endtime) are usually rendered with 6 digits precision, e.g.
2019-01-18T17:54:49.637515Z. This can be parsed in Python with something like

ts = datetime.datetime.strptime(tsStrg, '%Y-%m-%dT%H:%M:%S.%fZ')"

However, whenever the fraction is ".000000" (so in 1 of 1 million cases in the average), that is dropped, as for example in the line (from a real pcap)

<tcpflow startime='2019-01-18T17:54:48Z' endtime='2019-01-18T17:54:49.637515Z' ...

The problem is that above strptime fails in this case. Because it happens rarely, the problem can strike pretty late. The only workaround I found is using something like

try:
  ts = datetime.datetime.strptime(tsStrg, '%Y-%m-%dT%H:%M:%S.%fZ')
except ValueError:
  ts = datetime.datetime.strptime(tsStrg, '%Y-%m-%dT%H:%M:%SZ')

I think the better solution would be if tcpflow would not suppress the 0's.

It could be fixed (if this is considered as unwanted behaviour) in dfxml/src/dfxml_writer.h by removing lines 212 and 215 (making appending the fraction independent of the (ts.tv_usec>0) condition)

@simsong
Copy link
Owner

simsong commented Mar 4, 2019 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants