TZTimestamp Example

, ,
1

Imported from previous forum

2

Can someone point me to an example xml using TZTimestamp_t. I am having difficulty parsing the format YYYYMMDD-HH:MM:SS[Z | [ + | - hh[:mm]]] described in the spec. Also, is theis the same format for the minValue, maxValue, constValue fields.

3

The attributes, minValue, maxValue and constValue, are of type time (or xs:time) when xs:type = TZTimestamp_t.

In the spec the type, time, is defined as:
“Time specified in the format “hh:mm[:ss]” or “hh:mm[:ss]{+,-}hh:mm”. In the later format the offset from UTC is provided.”

I have not yet come across a custom tag of type TZTimestamp to date. Most algo providers require all their time-related custom tags to be in UTCTimestamp format. (Do you really need a TZTimestamp?)

However, as an example we can consider a New York-based algo provider who wishes to receive a custom tag named “TriggerTime” (tag 8099) of type TZTimestamp. The provider would declare this with a element such as:

or, perhaps

Althought it seems to me that this 2nd case should be avoided as it’s not clear whether maxValue should be “21:00:00-05:00” or “16:00:00+05:00”. I find no benefit in using the hh:mm[:ss]{+,-}hh:mm format because it gives no help in determining whether daylight savings is in effect. PAra,meter/@localMktTimezone provides that information.

-Greg

4

The attributes, minValue, maxValue and constValue, are of type time (or xs:time) when xs:type = TZTimestamp_t.

In the spec the type, time, is defined as:
“Time specified in the format “hh:mm[:ss]” or “hh:mm[:ss]{+,-}hh:mm”. In the later format the offset from UTC is provided.”

I have not yet come across a custom tag of type TZTimestamp to date. Most algo providers require all their time-related custom tags to be in UTCTimestamp format. (Do you really need a TZTimestamp?)

However, as an example we can consider a New York-based algo provider who wishes to receive a custom tag named “TriggerTime” (tag 8099) of type TZTimestamp. The provider would declare this with a element such as:

or, perhaps

Althought it seems to me that this 2nd case should be avoided as it’s not clear whether maxValue should be “21:00:00-05:00” or “16:00:00+05:00”. I find no benefit in using the hh:mm[:ss]{+,-}hh:mm format because it gives no help in determining whether daylight savings is in effect. PAra,meter/@localMktTimezone provides that information.

-Greg

Thanks for the reply. As far as supporting the TZTimeOnly_t and TZTimestamp_t, it is part of the spec so I have been trying support it in our order app.

The spec has TZTimezone as “based on ISO 8601”. Unfortunately, it is not exactly 8601 so the 8601 parsers I have tried won’t recognize the format.

Maybe I’ll wait to see if any of our brokers need TZTime…