TimeInForce (FIX tag 59)

charFIX 4.4FIX 4.2FIX 5.0 SP2

TimeInForce (tag 59) is a char field defined in FIX 4.4, FIX 4.2 and FIX 5.0 SP2. It appears in 10 message types, always optionally. It is an enumerated field with 8 defined values.

At a glance

Tag
59
Name
TimeInForce
Datatype
char
Dialects
FIX 4.4, FIX 4.2 and FIX 5.0 SP2
Messages
10
Valid values
8

What the specification says

FIX 4.4

Specifies how long the order remains in effect. Absence of this field is interpreted as DAY.

FIX 4.2

Specifies how long the order remains in effect. Absence of this field is interpreted as DAY.

FIX 5.0 SP2

Specifies how long the order remains in effect. Absence of this field is interpreted as DAY. NOTE not applicable to CIV Orders.

Descriptions are quoted from the FIX Orchestra sources under the Apache 2.0 licence.

A real message using tag 59

NewOrderSingle · FIX 4.4
TagFieldWire valueMeaning
8BeginStringFIX.4.4
9BodyLength116
35MsgTypeDOrder – Single
49SenderCompIDBOARTEAM
56TargetCompIDCOUNTERPARTY
34MsgSeqNum2
52SendingTime20240101-12:00:00.000
11ClOrdIDORD-10042
54Side1Buy
60TransactTime20240101-12:00:00.000
40OrdType1Market
59TimeInForce0Day (or session)
10CheckSum209
Edit and decode it yourself

Shown with | separators for readability. On the wire FIX uses SOH (0x01), an invisible control byte — and because BodyLength and CheckSum are computed over the actual bytes, the two forms have different checksums. Both are valid and both decode here.

Open in the full decoder →

Generated from the FIX 4.4 dictionary and verified at build time: it parses and validates with no issues. Open the decoder to try your own message.

Valid values

A value outside this list is not a parse error — the message still decodes — but validate() reports it as validate/value-not-in-enum.

ValueMeaningSymbolic nameDialects
0Day (or session)DAY / DayFIX 4.4, FIX 4.2, FIX 5.0 SP2
1Good Till Cancel (GTC)GOOD_TILL_CANCEL / GoodTillCancelFIX 4.4, FIX 4.2, FIX 5.0 SP2
2At the Opening (OPG)AT_THE_OPENING / AtTheOpeningFIX 4.4, FIX 4.2, FIX 5.0 SP2
3Immediate or Cancel (IOC)IMMEDIATE_OR_CANCEL / ImmediateOrCancelFIX 4.4, FIX 4.2, FIX 5.0 SP2
4Fill or Kill (FOK)FILL_OR_KILL / FillOrKillFIX 4.4, FIX 4.2, FIX 5.0 SP2
5Good Till Crossing (GTX)GOOD_TILL_CROSSING / GoodTillCrossingFIX 4.4, FIX 4.2, FIX 5.0 SP2
6Good Till DateGOOD_TILL_DATE / GoodTillDateFIX 4.4, FIX 4.2, FIX 5.0 SP2
7At the CloseAT_THE_CLOSEFIX 4.4, FIX 5.0 SP2
8Good Through CrossingGOOD_THROUGH_CROSSINGFIX 5.0 SP2
9At CrossingAT_CROSSINGFIX 5.0 SP2

Where tag 59 appears

Requiredness is a property of the message, not of the field: the same tag can be optional in one message and conditionally required in another.

MessageMsgTypeFIX 4.4FIX 4.2FIX 5.0 SP2Where in the message
CrossOrderCancelReplaceRequesttOptionalOptionaldirectly on the message body
DerivativeSecurityListAAOptionalinside DerivativeSecurityDefinition › MarketSegmentGrp › SecurityTradingRules › TradingSessionRulesGrp › TradingSessionRules › TimeInForceRules
DerivativeSecurityListUpdateReportBROptionalinside DerivativeSecurityDefinition › MarketSegmentGrp › SecurityTradingRules › TradingSessionRulesGrp › TradingSessionRules › TimeInForceRules
ExecutionReport8OptionalOptionalOptionaldirectly on the message body
MarketDataIncrementalRefreshXOptionalOptionalOptionalinside the MDIncGrp component
MarketDataSnapshotFullRefreshWOptionalOptionalOptionalinside the MDFullGrp component
MarketDefinitionBUOptionalinside the TimeInForceRules component
MarketDefinitionUpdateReportBVOptionalinside the TimeInForceRules component
MultilegOrderCancelReplaceACOptionalOptionaldirectly on the message body
NewOrderCrosssOptionalOptionaldirectly on the message body
NewOrderListEOptionalOptionalOptionalinside the ListOrdGrp component
NewOrderMultilegABOptionalOptionaldirectly on the message body
NewOrderSingleDOptionalOptionalOptionaldirectly on the message body
OrderCancelReplaceRequestGOptionalOptionalOptionaldirectly on the message body
SecurityDefinitiondOptionalinside MarketSegmentGrp › SecurityTradingRules › TradingSessionRulesGrp › TradingSessionRules › TimeInForceRules
SecurityDefinitionUpdateReportBPOptionalinside MarketSegmentGrp › SecurityTradingRules › TradingSessionRulesGrp › TradingSessionRules › TimeInForceRules
SecurityListyOptionalinside SecListGrp › SecurityTradingRules › TradingSessionRulesGrp › TradingSessionRules › TimeInForceRules
SecurityListUpdateReportBKOptionalinside SecLstUpdRelSymGrp › SecurityTradingRules › TradingSessionRulesGrp › TradingSessionRules › TimeInForceRules
TradeCaptureReportAEOptionalinside TrdCapRptSideGrp › TradeReportOrderDetail
TradeCaptureReportAckAROptionalinside TrdCapRptAckSideGrp › TradeReportOrderDetail
TradingSessionListBJOptionalinside TrdSessLstGrp › TradingSessionRules › TimeInForceRules
TradingSessionListUpdateReportBSOptionalinside TrdSessLstGrp › TradingSessionRules › TimeInForceRules

Wire format

A single character. Most char fields are enumerated, so the value is one of a fixed set rather than arbitrary text. @boarteam/fix keeps the value as a string and, for enumerated fields, reports validate/value-not-in-enum when it is not a defined value.

Read tag 59 in TypeScript

decode.tsts
import { createFixEngine } from "@boarteam/fix";import { dictionary } from "@boarteam/fix-dict-fix44";const fix = createFixEngine(dictionary);const { message, issues } = fix.parse(raw);const timeInForce = message.fields[59]?.raw;// e.g. "0" — Day (or session)// The dictionary also carries the labels:const label = fix.dictionary  .fieldByTag(59)  ?.enumValues?.find((e) => e.value === timeInForce)  ?.description;

Other char fields

Decode this in your own code

The same engine that produced the decoded example above is an Apache-2.0 npm package with zero runtime dependencies. It runs in Node and in the browser, and parse() returns problems as data instead of throwing.

npm i @boarteam/fix @boarteam/fix-dict-fix44