I'm running QuickFix with the Python API and connecting to a TT FIX Adapter using FIX4.2
I'm successfully logging on and sending a market data request. The replies are fine. In my message logs (both screen logs and file logs) I am getting a SendingTime (field 52) that looks something like this:
52=20130207-02:38:32.212
However, when I try to get this field and print it to the terminal or to a file, everything is the same except the milliseconds are dropped. So the result is always:
52=20130207-02:38:32
Obviously this is bad. I can't think why the milliseconds would be present at first, and then get dropped when I'm accessing them.
Maybe this is an artifact of Python, which accesses attributes with the '.' character? But this seems stupid, because SendingTime is a string, and last I checked periods were allowed in strings.
Any help would be great, I'd really like to be able to print accurate timestamps to files.
Thanks,
Wapiti
Try extracting the field with FieldMap's const std::string & getField (int field) function. That will get your field as a string, without trying to convert it to a date type. I bet that will preserve the milliseconds, at least textually.
Sorry I can't help with why Python is losing the ms. I just don't know enough about the Python wrapper.
EDIT: Nope, not the right answer. I didn't know you weren't extracting the field from the header. (You can still use this function on the header, of course.)
I solved my problem by specifying the getField function to look at the header. So:
sendingTime= quickfix.SendingTime()
print sendingTime, "\n"
message.getHeader().getField(sendingTime)
print sendingTime, "\n"
The first printed line will be the sending time with milliseconds rounded off (I have no idea why), it lookes like 52=20130207-02:38:32
The second printed line actually looks into the header (where field 52 resides) and gets the whole field, it will look like:
52=20130207-02:38:32.212
This explains why when I tried message.getField(sendingTime) I was getting a Field not Found error.
