Imported from previous forum
Does anyone know the answer to http://www.fixtradingcommunity.org/pg/discussions/topicpost/2810689/ ?
Hello, we have a String field on our FIX API which represents a time ‘duration’ in the HH:MM:SS format. This represents a duration and not a point in time. Is there anyway to represent this field using ATDL? The UTCTimeOnly type with a clock control almost fits as it is in the right format and the clock UI control allows the user to enter the time easily, but the ATDL code (atdl4j for example) converts it to a UTC time before sending it on the wire. Since this is a duration and doesn’t represent a point in time, there is no need for any time zone conversion and I just want the raw value directly. For example, if the user enters a duration of one hour and 30 minutes like this: 01:30:00 that is the value I want on the wire, and not the UTC representation of 1:30am. Any recommendations? Can I somehow use TZTimeOnly to achieve this? Any other recommendations other than forcing the user to enter the full string directly into a string field? Thanks for your help.
Aaron,
Thanks for your question - certainly sounds like a common use-case so I suspect FIXatdl – under the hood – will easily support what you are trying to do.
When we moved FIXatdl from v1.0 to v1.1 (after getting major detailed feedback from the OMS community) we specifically isolated the GUI components/screen widgets side, from the FIX wire protocol side, for maximum flexibility. When we looked widely at the then current FIX implementations we found considerable variation in the actual field use of the FIX wire protocol (and not infrequent cases where people were using FIX in quite unique, sometimes totally non-standard ways). In FIXatdl we really worked to be exceptionally accommodating to standing implementations.
Binding a clock control on the GUI to a FIX wire string variable (or any other FIX datatype) on the wire, should be easily possible (at least at the FIXatdl standard design level).
Scott Atwel, Jonny Shields or Danilo Tuler (see GitHub) would be great to consult on the atdl4j internals - hopefully commenting here to retain the thread.
Setting an order’s duration in the market is so commonplace I can’t imagine there isn’t a quick and easy way to do what you want in atdl4j.
Rick
Thanks Rick for your response. If I understand correctly, you are saying that from an ATDL perspective, I should be able to use a Clock control to send a String type parameter over the wire? But it’s up to the ATDL parser/renderer implementation to handle this correctly? Thanks.
Most brokers implement an “End Time” (generally ExpireTime (126), and optionally EffectiveTime (168)) vs. expressing a duration per-se. The value sent over the wire must be as the receiving side expects (eg in the format expected). You could use a Clock control to display/capture a Time (which inherently also implies/needs a Date). The FIX Protocol standard’s expression of a time is a UTCTimestamp, and in FIXatdl that would be UTCTimestampT (note that you can specify a timezone to use for rendering, and FIXatdl specifies that its wire representation should match the FIX Protocol’s UTCTimestamp data type). You could also implement a basic TextField in which case the string transmitted over the wire would be as-entered.
An additional thought, and after re-reading:
“The UTCTimeOnly type with a clock control almost fits as it is in the right format and the clock UI control allows the user to enter the time easily, but the ATDL code (atdl4j for example) converts it to a UTC time before sending it on the wire. Since this is a duration and doesn’t represent a point in time, there is no need for any time zone conversion and I just want the raw value directly.”
Could you use UTCTimeOnly parameter and Control, specify UTC as the LocalTz, specify “00:00:00” for InitialValue, and on the receiving side recognize the value provided as an expression of HH:MM:SS duration? The idea being that if you ‘fix’ the TZ to UTC, and init it to 0, then you should be able to rely upon any value as a consistent ‘offset’ from 0.
Scott, which of the localMktTz TZ codes would I use for UTC? I didn’t find an obvious one. Thanks
Aaron – yes the ATDL parser/renderer implementation must handle the various “devil in the details.”
Scott/Aaron – in FIXatdl we had a concept of “helper controls/widgets” – i.e. controls that were to be part of the UI (perhaps a dynamic UI), that just helped out making the screen perform as designed. These were “thrown away” after the UI interaction was complete, they did not place any values on the FIX wire. (I.e. “view” (screen), separation from “model” (FIX wire), from “control” (dynamic screen control, validation, and packing up data on the FIX wire control). We also had the ability to hide controls/widgets (set to invisible).
I remember a long an heated debate on whether FIXatd could be implemented in such a way that programmatically it changed a human entered “screen value” into something different in the background and it actually went out on the FIX wire as a modified/computed value. Recall there were strong arguments for and against that, but think we ultimately opted for “yes that’s possible”.
Scott, which of the localMktTz TZ codes would I use for UTC? I didn’t find an obvious one. Thanks
Aaron, in Java (eg atdl4j), this is a valid string representation that can be used to construct a Java Timezone object. Timezone support, and the suite of timezones, can vary (and their rules can change from one JVM version to another). If you look at your JVM’s installation, and specifically at the contents of its “lib\zi” folder, then you can see the timezones installed. Examples are “America/New_York”, “Europe/London”, “Asia/Hong_Kong”. To answer your question, for UTC, you should be able to use “Etc/UTC”.
Scott, I dont see ‘Etc/UTC’ listed as a valid timezone in fixatdl-timezones-1-1.xsd. Doesn’t the time zone have to be listed there under ‘LocalMktTz_t’ to be valid in ATDL? Thanks.
Aaron,
Well, I think you are probably going to find using a text field with an init string of “00:00:00” (or “00:00”) is probably going to be the easiest (or use EffectiveTime and EndTime, as previously suggested).
-
fixatdl-timezones-1-1.xsd is missing all of the “Etc/*” entries, thus does not have “Etc/UTC”. atdl4j’s Timezone.class was ‘generated’ (via JAXB) from the XSD that shipped with FIXatdl 1.1. I did some testing, and, in atdl4j, you can’t load the FIXatdl file if it specifies a localMktTz value that is not in that enum class.
-
I did some testing using “Europe/London” (not the same as UTC, given that London observes Daylight Savings), and I found that atdl4j’s Control handling of localMktTz is simply to ‘know’ what timezone the initValue (if specified) is expressed in. Ultimately, it still renders the time according to the local PC’s clock. For instance, I’m -6 hours from UTC, atdl4j renders “06:00 pm” (or “06:02”) but generates the wire value of “00:00:00” (or “00:00:02”). While the wire value is what you’re looking for, the rendered display value and user-entry is not.
Hi,
I have a question related to xsd validation, I am using Fixatdl-1.1-with-Errata-20101221. UTCDateOnly is define like:
Stringstring field representing Date represented in UTC (Universal Time Coordinated, also known as “GMT”) in YYYYMMDD format. This special-purpose field is paired with UTCTimeOnly to form a proper UTCTimestamp for bandwidth-sensitive messages.
Valid values:
YYYY = 0000-9999, MM = 01-12, DD = 01-31.
but the restriction is xs:date which has the format according to http://www.w3schools.com/schema/schema_dtypes_date.asp “YYYY-MM-DD”
When I try to validate an xml file I get the following error:
cvc-datatype-valid.1.2.1: ‘20120506’ is not a valid value for ‘date’.,
cvc-attribute.3: The value ‘20120506’ of attribute ‘constValue’ on element ‘Parameter’ is not valid with respect to its type, ‘UTCDateOnly’
Is it any known issue? Do I do something wrong?
Another issue is that we map UTCTimestamp_t, UTCDateOnly_t and UTCTimeOnly_t parameters to Clock_t control, in that case for UTCDateOnly_t default value like “20120304” will fails validation saying that it is not a valid time.
Regards,
Ovidiu
Ovidiu,
Have you tried using the xml schema format for date? E.g. “2010-03-04”.
The XML Schema files definitely require this format to be used. The specification document however seems to have done a poor job explaining probably because all the types used in FIXatdl are described in one table. In this table the description is often taken directly from the FIX specification which describes how the data is transmitted in FIX not how it is to be represented in FIXatdl. Perhaps there was a better way to organize these type descriptions. But please try the xsd:date format and see if that works.
-Greg
Note also that a FIXatdl implementation should handle converting to/from the appropriate FIX wire value (“20120304”) within the FIX message itself, but, as Greg stated, FIXatdl uses the XML Schema “xs:” data types vs. FIX’s wire values where applicable.