[QFJ-146] Subclasses of quickfix.field.UtcTimeStampField don't preserve milliseconds during creation Created: 28/Feb/07  Updated: 01/Mar/07  Resolved: 01/Mar/07

Status: Closed
Project: QuickFIX/J
Component/s: Engine
Affects Version/s: 1.0.5
Fix Version/s: None

Type: Bug Priority: Default
Reporter: Toli Kuznets Assignee: Toli Kuznets
Resolution: Fixed Votes: 0
Labels: None


 Description   

the UtcTimeStampField has a boolean argument whether or not t preserve the millisecond field from a timestamp.

However, none of the subclasses call that constructor, as a result, the milliseconds are always lost when you round-trip something like
Date aDate = new Date();
assertEquals("rountdrip fails", aDate.getTime(), (new EffectiveTime(aDate)).getValue().getTime());

Message msg = new Message();
msg.setField(new EffectiveTime(aDate));
assertEquals("rountdrip from msg fails", aDate.getTime(), msg.getField(new EffectiveTime()).getValue().getTime());

Fails in the second assert with: rountdrip from msg fails expected:<1172696741599> but was:<1172696741000>

So the milliseconds are lost when a subclass of UtcTimeStampField is retrieved from the message.

The 2nd part is that FieldMap doesn't later use the UtcTimeStampField.showMilliseconds() when it stores the fields in the message.
So the values are lost even at sending (marshaling) time, not just at unmarshaling.

Interestingly, there seems to be a similar error in Quickfix as well: http://www.quickfixengine.org/bugtracker/bug.php?op=show&bugid=1&pos=0



 Comments   
Comment by Toli Kuznets [ 01/Mar/07 ]

Modified the xlslt to call the constructors in UtcTimeStamp/OnlyField classes that preserves milliseconds.
Modified the setter code in FieldMap to use the showMilliseconds() values from Utcxxx fields during conversion.

Comment by Toli Kuznets [ 01/Mar/07 ]

Fix checked in revision 598.

Generated at Sat Nov 23 10:59:27 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.