quickfix-developers

RE: [Quickfix-developers] Millisecond resolution in UTCTimeStamp

[Daniel M. <Dan...@ma...>]

My changes only add milliseconds if the BeginString in the message
header is >=3D FIX.4.2 . =20
The old conversion routines do NOT throw an exception if there are
milliseconds in the time stamp, they just get quietly
ignored. The call to strptime() was not bothered by them.  My opinion
would be that anyone talking to a > FIX.4.2 connection
needs to be prepared to process milliseconds per the specification.

I will add the configuration setting if you still think it is needed.

Daniel


-----Original Message-----
From: Miller, Oren [mailto:OM...@ri...]=20
Sent: Wednesday, November 05, 2003 2:37 PM
To: Daniel May; qui...@li...
Cc: Joerg Thoennes
Subject: RE: [Quickfix-developers] Millisecond resolution in
UTCTimeStamp

I'd also like to add a configuration setting that can turn on and off
sending messages with milliseconds.  There may be some fix engines
people want to talk to (QF 1.0 to 1.6 for instance!) that will not be
able to handle them.


-----Original Message-----
From:	Daniel May [mailto:Dan...@ma...]
Sent:	Wed 11/5/2003 9:29 AM
To:	qui...@li...
Cc:	Miller, Oren; Joerg Thoennes
Subject:	 [Quickfix-developers] Millisecond resolution in
UTCTimeStamp
I have checked in the code changes that allow millisecond time stamp
resolution per the FIX 4.2 and later specification.  QF will check
message headers and include the milliseconds if the BeginString >=3D
FIX.4.2 .
There were several files that needed to be modified, I have listed them
below along with a few caveats concerning the implementation.

FieldTypes.h and FieldType.cpp
	These files contain the bulk of the code changes.  I added a
private member to the class FIX::UtcTimeStamp to hold milliseconds,
m_ms.  I added a set/get for access.  When you create a
FIX::UtcTimeStamp, the default has always been to set it to the current
time/date, this remains the same, and the millisecond field is
populated.  I chose to use
ftime() to replace time() since
it returns the time_t structure the original FIX::UtcTimeStamp was
derived from. PLEASE NOTE:  Under MS Windows (NT,2K,XP), ftime() has at
best a resolution of 10ms on a single processor machine, and 15ms on a
multiple processor machine.


FieldConvertors.h
	When using UtcTimeStampConvertor to convert to a std::string,
there is an optional bool parameter (default false) which will force the
conversion to include .sss in the string.  When converting from a
std::string to a UtcTimeStamp, I will always parse the milliseconds if
they are present in the format HH:MM:SS.sss, with some basic validation.
The same holds true for UtcTimeOnlyConvertor.

Session.cpp
	When setting the SendingTime() field, I check for a BegingString
>=3D BeginString_FIX42, and
include milliseconds.


fieldconvertorstestcase.cpp sessiontestcase.cpp utctimeonlytestcase.cpp
utctimestamptestcase.cpp
	Several of the test cases had to be modified to properly
initialize the milliseconds in UtcTimeStamp.
I also added a test case to verify the conversion routines.
=09

=20
Daniel May
da...@so...

RE: [Quickfix-developers] Millisecond resolution in UTCTimeStamp

[Oren M. <ore...@ya...>]

I agree that any compliant FIX engine should support
it, but I'm sure all do, and most importantly we know
for a fact that earlier versions of QF do not.  If the
milliseconds cannot be turned off, that will create a
problem that version 1.7 of QF will not be able to
talk to earlier versions of QF running running FIX 4.2
or later.

The problem is not whether the new version will throw
an exception, I'm sure it will handle everything find.
 My concern is that when we send a message with
milliseconds, if an earlier version of QF receives
this message it will be rejected.  If we can't turn
off the milliseconds, then systems running different
versions of QF will be unable to communicate.

--- Daniel May <Dan...@ma...> wrote:
> My changes only add milliseconds if the BeginString
> in the message
> header is >= FIX.4.2 .  
> The old conversion routines do NOT throw an
> exception if there are
> milliseconds in the time stamp, they just get
> quietly
> ignored. The call to strptime() was not bothered by
> them.  My opinion
> would be that anyone talking to a > FIX.4.2
> connection
> needs to be prepared to process milliseconds per the
> specification.
> 
> I will add the configuration setting if you still
> think it is needed.
> 
> Daniel
> 
> 
> -----Original Message-----
> From: Miller, Oren
> [mailto:OM...@ri...] 
> Sent: Wednesday, November 05, 2003 2:37 PM
> To: Daniel May;
> qui...@li...
> Cc: Joerg Thoennes
> Subject: RE: [Quickfix-developers] Millisecond
> resolution in
> UTCTimeStamp
> 
> I'd also like to add a configuration setting that
> can turn on and off
> sending messages with milliseconds.  There may be
> some fix engines
> people want to talk to (QF 1.0 to 1.6 for instance!)
> that will not be
> able to handle them.
> 
> 
> -----Original Message-----
> From:	Daniel May [mailto:Dan...@ma...]
> Sent:	Wed 11/5/2003 9:29 AM
> To:	qui...@li...
> Cc:	Miller, Oren; Joerg Thoennes
> Subject:	 [Quickfix-developers] Millisecond
> resolution in
> UTCTimeStamp
> I have checked in the code changes that allow
> millisecond time stamp
> resolution per the FIX 4.2 and later specification. 
> QF will check
> message headers and include the milliseconds if the
> BeginString >=
> FIX.4.2 .
> There were several files that needed to be modified,
> I have listed them
> below along with a few caveats concerning the
> implementation.
> 
> FieldTypes.h and FieldType.cpp
> 	These files contain the bulk of the code changes. 
> I added a
> private member to the class FIX::UtcTimeStamp to
> hold milliseconds,
> m_ms.  I added a set/get for access.  When you
> create a
> FIX::UtcTimeStamp, the default has always been to
> set it to the current
> time/date, this remains the same, and the
> millisecond field is
> populated.  I chose to use
> ftime() to replace time() since
> it returns the time_t structure the original
> FIX::UtcTimeStamp was
> derived from. PLEASE NOTE:  Under MS Windows
> (NT,2K,XP), ftime() has at
> best a resolution of 10ms on a single processor
> machine, and 15ms on a
> multiple processor machine.
> 
> 
> FieldConvertors.h
> 	When using UtcTimeStampConvertor to convert to a
> std::string,
> there is an optional bool parameter (default false)
> which will force the
> conversion to include .sss in the string.  When
> converting from a
> std::string to a UtcTimeStamp, I will always parse
> the milliseconds if
> they are present in the format HH:MM:SS.sss, with
> some basic validation.
> The same holds true for UtcTimeOnlyConvertor.
> 
> Session.cpp
> 	When setting the SendingTime() field, I check for a
> BegingString
> >= BeginString_FIX42, and
> include milliseconds.
> 
> 
> fieldconvertorstestcase.cpp sessiontestcase.cpp
> utctimeonlytestcase.cpp
> utctimestamptestcase.cpp
> 	Several of the test cases had to be modified to
> properly
> initialize the milliseconds in UtcTimeStamp.
> I also added a test case to verify the conversion
> routines.
> 	
> 
>  
> Daniel May
> da...@so...
> 
> 
> 
> 
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback
> Program.
> Does SourceForge.net help you be more productive? 
> Does it
> help you create better code?   SHARE THE LOVE, and
> help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

RE: [Quickfix-developers] Millisecond resolution in UTCTimeStamp

[Oren M. <ore...@ya...>]

In my last message "But I'm sure all do" should read
"but I'm not sure all do"

--- Daniel May <Dan...@ma...> wrote:
> My changes only add milliseconds if the BeginString
> in the message
> header is >= FIX.4.2 .  
> The old conversion routines do NOT throw an
> exception if there are
> milliseconds in the time stamp, they just get
> quietly
> ignored. The call to strptime() was not bothered by
> them.  My opinion
> would be that anyone talking to a > FIX.4.2
> connection
> needs to be prepared to process milliseconds per the
> specification.
> 
> I will add the configuration setting if you still
> think it is needed.
> 
> Daniel
> 
> 
> -----Original Message-----
> From: Miller, Oren
> [mailto:OM...@ri...] 
> Sent: Wednesday, November 05, 2003 2:37 PM
> To: Daniel May;
> qui...@li...
> Cc: Joerg Thoennes
> Subject: RE: [Quickfix-developers] Millisecond
> resolution in
> UTCTimeStamp
> 
> I'd also like to add a configuration setting that
> can turn on and off
> sending messages with milliseconds.  There may be
> some fix engines
> people want to talk to (QF 1.0 to 1.6 for instance!)
> that will not be
> able to handle them.
> 
> 
> -----Original Message-----
> From:	Daniel May [mailto:Dan...@ma...]
> Sent:	Wed 11/5/2003 9:29 AM
> To:	qui...@li...
> Cc:	Miller, Oren; Joerg Thoennes
> Subject:	 [Quickfix-developers] Millisecond
> resolution in
> UTCTimeStamp
> I have checked in the code changes that allow
> millisecond time stamp
> resolution per the FIX 4.2 and later specification. 
> QF will check
> message headers and include the milliseconds if the
> BeginString >=
> FIX.4.2 .
> There were several files that needed to be modified,
> I have listed them
> below along with a few caveats concerning the
> implementation.
> 
> FieldTypes.h and FieldType.cpp
> 	These files contain the bulk of the code changes. 
> I added a
> private member to the class FIX::UtcTimeStamp to
> hold milliseconds,
> m_ms.  I added a set/get for access.  When you
> create a
> FIX::UtcTimeStamp, the default has always been to
> set it to the current
> time/date, this remains the same, and the
> millisecond field is
> populated.  I chose to use
> ftime() to replace time() since
> it returns the time_t structure the original
> FIX::UtcTimeStamp was
> derived from. PLEASE NOTE:  Under MS Windows
> (NT,2K,XP), ftime() has at
> best a resolution of 10ms on a single processor
> machine, and 15ms on a
> multiple processor machine.
> 
> 
> FieldConvertors.h
> 	When using UtcTimeStampConvertor to convert to a
> std::string,
> there is an optional bool parameter (default false)
> which will force the
> conversion to include .sss in the string.  When
> converting from a
> std::string to a UtcTimeStamp, I will always parse
> the milliseconds if
> they are present in the format HH:MM:SS.sss, with
> some basic validation.
> The same holds true for UtcTimeOnlyConvertor.
> 
> Session.cpp
> 	When setting the SendingTime() field, I check for a
> BegingString
> >= BeginString_FIX42, and
> include milliseconds.
> 
> 
> fieldconvertorstestcase.cpp sessiontestcase.cpp
> utctimeonlytestcase.cpp
> utctimestamptestcase.cpp
> 	Several of the test cases had to be modified to
> properly
> initialize the milliseconds in UtcTimeStamp.
> I also added a test case to verify the conversion
> routines.
> 	
> 
>  
> Daniel May
> da...@so...
> 
> 
> 
> 
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback
> Program.
> Does SourceForge.net help you be more productive? 
> Does it
> help you create better code?   SHARE THE LOVE, and
> help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: [Quickfix-developers] Millisecond resolution in UTCTimeStamp

[Joerg T. <Joe...@ma...>]

Daniel May wrote:
> My changes only add milliseconds if the BeginString in the message
> header is >= FIX.4.2 .  
> The old conversion routines do NOT throw an exception if there are
> milliseconds in the time stamp, they just get quietly
> ignored. The call to strptime() was not bothered by them.  My opinion
> would be that anyone talking to a > FIX.4.2 connection
> needs to be prepared to process milliseconds per the specification.
> 
> I will add the configuration setting if you still think it is needed.

IMHO, you should add this option. There are other options (e.g. for out
of order fields) which disable FIX compliant behaviour to cope with the
pecularities of the different FIX engines.

Cheers, Jörg

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen