| char | | Single character value, can include any alphanumeric character or punctuation except the delimiter. All char fields are case sensitive (i.e. m != M). | |
0
xs:string
Single character value, can include any alphanumeric character or punctuation except the delimiter. All char fields are case sensitive (i.e. m != M).
|
| int | | Sequence of digits without commas or decimals and optional sign character (ASCII characters "-" and "0" - "9" ). The sign character utilizes one byte (i.e. positive int is "99999" while negative int is "-99999"). Note that int values may contain leading zeros (e.g. "00023" = "23"). | 723 in field 21 would be mapped int as |21=723|. -723 in field 12 would be mapped int as |12=-723|. |
1
xs:integer
Sequence of digits without commas or decimals and optional sign character (ASCII characters "-" and "0" - "9" ). The sign character utilizes one byte (i.e. positive int is "99999" while negative int is "-99999"). Note that int values may contain leading zeros (e.g. "00023" = "23").
723 in field 21 would be mapped int as |21=723|. -723 in field 12 would be mapped int as |12=-723|.
|
| float | | Sequence of digits with optional decimal point and sign character (ASCII characters "-", "0" - "9" and "."); the absence of the decimal point within the string will be interpreted as the float representation of an integer value. All float fields must accommodate up to fifteen significant digits. The number of decimal places used should be a factor of business/market needs and mutual agreement between counterparties. Note that float values may contain leading zeros (e.g. "00023.23" = "23.23") and may contain or omit trailing zeros after the decimal point (e.g. "23.0" = "23.0000" = "23" = "23."). Note that fields which are derived from float may contain negative values unless explicitly specified otherwise. | |
1
xs:decimal
Sequence of digits with optional decimal point and sign character (ASCII characters "-", "0" - "9" and "."); the absence of the decimal point within the string will be interpreted as the float representation of an integer value. All float fields must accommodate up to fifteen significant digits. The number of decimal places used should be a factor of business/market needs and mutual agreement between counterparties. Note that float values may contain leading zeros (e.g. "00023.23" = "23.23") and may contain or omit trailing zeros after the decimal point (e.g. "23.0" = "23.0000" = "23" = "23."). Note that fields which are derived from float may contain negative values unless explicitly specified otherwise.
|
| UTCTimestamp | | string field representing time/date combination represented in UTC (Universal Time Coordinated, also known as "GMT") in either YYYYMMDD-HH:MM:SS (whole seconds) or YYYYMMDD-HH:MM:SS.sss* format, colons, dash, and period required.
Valid values:
YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 00-60 (60 only if UTC leap second), sss* fractions of seconds.
The fractions of seconds may be empty when no fractions of seconds are conveyed (in such a case the period is not conveyed), it may include 3 digits to convey milliseconds, 6 digits to convey microseconds, 9 digits to convey nanoseconds, 12 digits to convey picoseconds; Other number of digits may be used with bilateral agreement.
Leap Seconds: Note that UTC includes corrections for leap seconds, which are inserted to account for slowing of the rotation of the earth. Leap second insertion is declared by the International Earth Rotation Service (IERS) and has, since 1972, only occurred on the night of Dec. 31 or Jun 30. The IERS considers March 31 and September 30 as secondary dates for leap second insertion, but has never utilized these dates. During a leap second insertion, a UTCTimestamp field may read "19981231-23:59:59", "19981231-23:59:60", "19990101-00:00:00". (see http://tycho.usno.navy.mil/leapsec.html) | TransactTime(60)="20011217-09:30:47.123" millisecond
TransactTime(60)="20011217-09:30:47.123456" microseconds
TransactTime(60)="20011217-09:30:47.123456789" nanoseconds
TransactTime(60)="20011217-09:30:47.123456789123" picoseconds
|
0
xs:dateTime
string field representing date and time combination Universal Time Coordinated (UTC), also known as Greenwich Mean Time (GMT).
Its value space is described as the combination of date and time of day in the Chapter 5.4 of ISO 8601.
Valid values are in the format YYYY-MM-DDTHH:MM:SS.s where YYYY = 0000-9999 year, MM = 01-12 month, DD = 01-31 day, HH = 00-23 hour, MM = 00-59 minute, SS = 00-60 second (60 only if UTC leap second), and optionally one or more digits representing a decimal fraction of a second.
The punctuation of "-", ":" and the string value of "T" to separate the date and time are required. The "." is only required when sub-second time precision is specified.
Leap Seconds: Note that UTC includes corrections for leap seconds, which are inserted to account for slowing of the rotation of the earth. Leap second insertion is declared by the International Earth Rotation Service (IERS) and has, since 1972, only occurred on the night of Dec. 31 or Jun 30. The IERS considers March 31 and September 30 as secondary dates for leap second insertion, but has never utilized these dates. During a leap second insertion, a UTCTimestamp field may read "1998-12-31T23:59:59", "1998-12-31T23:59:60", "1999-01-01T00:00:00". (see http://tycho.usno.navy.mil/leapsec.html)
TxnTm="2001-12-17T09:30:47" seconds
TxnTm="20011217-09:30:47.123" milliseconds
TxnTm="20011217-09:30:47.123456" microseconds
TxnTm="20011217-09:30:47.123456789" nanoseconds
TxnTm="20011217-09:30:47.123456789123" picoseconds
|
| UTCTimeOnly | | string field representing time-only represented in UTC (Universal Time Coordinated, also known as "GMT") in either HH:MM:SS (whole seconds) or HH:MM:SS.sss* (milliseconds) format, colons, and period required. This special-purpose field is paired with UTCDateOnly to form a proper UTCTimestamp for bandwidth-sensitive messages.
Valid values:
HH = 00-23, MM = 00-59, SS = 00-60 (60 only if UTC leap second), sss* fractions of seconds. The fractions of seconds may be empty when no fractions of seconds are conveyed (in such a case the period is not conveyed), it may include 3 digits to convey milliseconds, 6 digits to convey microseconds, 9 digits to convey nanoseconds, 12 digits to convey picoseconds; Other number of digits may be used with bilateral agreement. | MDEntryTime(273)="13:20:00.123"milliseconds
MDEntryTime(273)="13:20:00.123456" microseconds
MDEntryTime(273)="13:20:00.123456789" nanoseconds
MDEntryTime(273)="13:20:00.123456789123" picoseconds
|
0
xs:time
string field representing time-only in Universal Time Coordinated (UTC), also known as Greenwich Mean Time (GMT).
Its value space is described as the time of day in the Chapter 5.4 of ISO 8601.
Valid values are in the format HH:MM:SS.s where HH = 00-23 hours, MM = 00-59 minutes, SS = 00-60 seconds (60 only if UTC leap second), and optionally s (one or more digits representing a decimal fraction of a second).
The punctuation of ":" between hours minutes and seconds are required. The "." is only required when sub-second time precision is specified.
This special-purpose field is paired with UTCDateOnly to form a proper UTCTimestamp for bandwidth-sensitive messages.
Tm="13:20:00.000" seconds
Tm="13:20:00.123"milliseconds
Tm="13:20:00.123456" microseconds
Tm="13:20:00.123456789" nanoseconds
Tm="13:20:00.123456789123" picoseconds
|
| TZTimeOnly | | string field representing the time represented based on ISO 8601. This is the time with a UTC offset to allow identification of local time and timezone of that time.
Format is HH:MM[:SS][Z | [ + | - hh[:mm]]] where HH = 00-23 hours, MM = 00-59 minutes, SS = 00-59 seconds, hh = 01-12 offset hours, mm = 00-59 offset minutes. | "07:39Z" is 07:39 UTC
"02:39-05" is five hours behind UTC, thus Eastern Time
"15:39+08" is eight hours ahead of UTC, Hong Kong/Singapore time
"13:09+05:30" is 5.5 hours ahead of UTC, India time |
1
xs:time
string field representing the time based on ISO 8601. This is the time with a Universal Time Coordinated(UTC) offset to allow identification of local time and timezone.
Its value space is described as the combination of date and time of day in the Chapter 5.4 of ISO 8601.
Valid values are in the format HH:MM[:SS][Z | [ + | - hh[:mm]]] where HH = 00-23 hours, MM = 00-59 minutes, SS = 00-59 seconds, hh = 01-12 offset hours, mm = 00-59 offset minutes.
The punctuation of ":" are required. The "Z" or "+" or "-" are optional to denote a time zone offset.
MatTm="07:39Z" is 07:39 UTC
MatTm="02:39-05" is five hours behind UTC, Eastern Time
MatTm="15:39+08" is eight hours ahead of UTC, Hong Kong/Singapore time
MatTm="13:09+05:30" is 5.5 hours ahead of UTC, India time
|
| TZTimestamp | | string field representing a time/date combination representing local time with an offset to UTC to allow identification of local time and timezone offset of that time. The representation is based on ISO 8601.
Format is YYYYMMDD-HH:MM:SS.sss*[Z | [ + | - hh[:mm]]] where YYYY = 0000 to 9999, MM = 01-12, DD = 01-31 HH = 00-23 hours, MM = 00-59 minutes, SS = 00-59 seconds, hh = 01-12 offset hours, mm = 00-59 offset minutes, sss* fractions of seconds. The fractions of seconds may be empty when no fractions of seconds are conveyed (in such a case the period is not conveyed), it may include 3 digits to convey milliseconds, 6 digits to convey microseconds, 9 digits to convey nanoseconds, 12 digits to convey picoseconds; Other number of digits may be used with bilateral agreement
| "20060901-07:39Z" is 07:39 UTC on 1st of September 2006
"20060901-02:39-05" is five hours behind UTC, thus Eastern Time on 1st of September 2006
"20060901-15:39+08" is eight hours ahead of UTC, Hong Kong/Singapore time on 1st of September 2006
"20060901-13:09+05:30" is 5.5 hours ahead of UTC, India time on 1st of September 2006
Using decimal seconds:
"20060901-13:09.123+05:30" milliseconds
"20060901-13:09.123456+05:30" microseconds
"20060901-13:09.123456789+05:30" nanoseconds
"20060901-13:09.123456789123+05:30" picoseconds
"20060901-13:09.123456789Z" nanoseconds UTC timezone
|
1
xs:dateTime
string field representing a date and time combination in local time with an optional offset to Univeral Time Coordinated (UTC). Its vaue space is described as the combination of date and time of day in the Chapter 5.4 of based on ISO 8601.
Valid values are in the fFormat is YYYY-MM-DD-THH:MM:SS.s*[Z | [ + | - hh[:mm]]] where YYYY = 0000 to 9999 year, MM = 01-12 month, DD = 01-31 day, HH = 00-23 hours, MM = 00-59 minutes, SS = 00-59 seconds, hh = 01-12 offset hours, mm = 00-59 offset minutes, and optionally sss (one or more digits representing a decimal fraction of a second), hh = 01-12 offset hours, mm = 00-59 offset minutes.
The punctuation of "-", ":" and the string value of "T" to separate the date and time are required. The "." is only required when sub-second time precision is specified. The "Z" or "+" or "-" are optional to denote an optional time zone offset.
"2006-09-01-T07:39Z" is 07:39 UTC on 1st of September 2006
"2006-09-01-T02:39-05" is five hours behind UTC, Eastern Time on 1st of September 2006
"2006-09-01-T15:39+08" is eight hours ahead of UTC, Hong Kong/Singapore time on 1st of September 2006
"2006-09-01-T13:09+05:30" is 5.5 hours ahead of UTC, India time on 1st of September 2006
Using decimal seconds:
"2006-09-01T13:09.123+05:30" milliseconds
"2006-09-01T13:09.123456+05:30" microseconds
"2006-09-01T13:09.123456789+05:30" nanoseconds
"2006-09-01T13:09.123456789123+05:30" picoseconds
"2006-09-01T13:09.123456789Z" nanoseconds UTC timezone
|
| LocalMktDate | | string field representing a Date of Local Market (as opposed to UTC) in YYYYMMDD format. This is the "normal" date field used by the FIX Protocol.
Valid values:
YYYY = 0000-9999, MM = 01-12, DD = 01-31
| MaturityDate(541)="20150724" |
0
xs:date
string field representing a Date of Local Market (as opposed to UTC) in YYYY-MM-DD format. This is the "normal" date field used by the FIX Protocol.
Valid values:
YYYY = 0000-9999, MM = 01-12, DD = 01-31.
MaturityDate(541)=”2015-07-24"
|