Re: [Quickfixj-users] UtcTimestampConverter question

[Christoph J. <chr...@ma...>]

I meant it has no native support for the TZ* fields and you will need to parse them as Strings and 
do the conversion yourself.
Of course QFJ has support for the UTC* fields and will convert them for you.

Cheers,
Chris.


On 24.09.20 09:55, Andrew Marlow wrote:
> Hello Christoph,
>
> Many thanks for your quick reply. I am bit confused though. You say that QFJ has no tentative 
> support for these types but it is QFJ that is throwing the exception in the converter. So I am not 
> sure what you mean.
>
> On Thu, 24 Sep 2020 at 00:26, Christoph John <chr...@ma... 
> <mailto:chr...@ma...>> wrote:
>
>     Hi Andrew,
>
>     please be aware that there are fields in FIX which follow the ISO 8601 date convention. The
>     type in that case is either TZTimestamp or TZDateOnly.
>     https://fiximate.fixtrading.org/en/FIX.5.0SP2_EP258/fix_datatypes.html
>     But there are only few fields with these data types. One of them is 1132/TZTransactTime, but I
>     assume that you are talking about tag 60/TransactTime, so yes, that one should be without a
>     "Z" in it.
>
>     QFJ has no native support for these fields but will treat them as String fields.
>
>     Cheers,
>     Chris.
>
>
>     On 23.09.20 19:27, Andrew Marlow wrote:
>>     QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>     QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>>     Hello everyone,
>>
>>     I am working on a feed program that connects to an ECN that speaks FIX, so I am using
>>     quickfixj. The protocol is 5.0sp2. I am using the latest version of quickfixj, version 2.2.0.
>>     I am seeing something very strange in the data that comes over. One of the messages has a
>>     transaction time that is supposed to be in UTC. However the data that comes over the wire has
>>     a trailing "Z" after the number of seconds. I presume that "Z" stands for Zulu time,
>>     basically an alias for UTC. That seems wrong to me. If the value is supposed to be in UTC
>>     then there is no need for any characters at the end to denote the timezone even if that
>>     timezone is UTC. quickfix agrees. We are getting a IncorrectDateFormat exception which seems
>>     to be thrown from UtcTimestampConverter.convert. I presumed that the ECN side would be using
>>     quickfixj to assemble the messages that we see and using the same data dictionary that they
>>     have given us, so how on earth can this happen? Any thoughts/ideas will be gratefully received.
>>
>>     -- 
>>     Regards,
>>
>>     Andrew Marlow
>>     http://www.andrewpetermarlow.co.uk
>>
>>
>>
>>     _______________________________________________
>>     Quickfixj-users mailing list
>>     Qui...@li...  <mailto:Qui...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>     -- 
>     Christoph John
>     Software Engineering
>     T +49 241 557080-28
>     chr...@ma...  <mailto:chr...@ma...>
>
>     MACD GmbH
>     Oppenhoffallee 103
>     52066 Aachen, Germany
>     www.macd.com  <http://www.macd.com>
>
>     Amtsgericht Aachen: HRB 8151
>     Ust.-Id: DE 813021663
>     Geschäftsführer: George Macdonald
>
>
>
> -- 
> Regards,
>
> Andrew Marlow
> http://www.andrewpetermarlow.co.uk
>

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald