Imported from previous forum
[ original email was from Davide Khalil - Reuters ]
All fields are specified in GMT in the FIX 4.0 specification but it does not specify daily reset criteria.
The daily reset of the FIX link theoretically also involves the End of Day processing which is based on Local time standards for clearing submission and such. With Daylight standard time, these processing times need to remain constant in the local time zone. To define the FIX connection reset times using GMT is not realistic.
The simple inclusion of an optional timezone related to each time field with the default being GMT would provide the flexibilty required by some users of FIX. Plus, the possibility for error when configuring many worldwide interfaces is much higher when the parties configure in GMT. To evidence this point, without referring to a map, what is the GMT offset of Sydney, Singapore, Moscow, Berlin, Anchorage and Sao Paulo.
[ original email was from Scott Atwell - ]
I don’t see a need for fields to specify the timezone for timestamps in the FIX spec. All timestamps are specified in GMT and (in FIX 4.0) include the date so it’s pretty easy for systems to convert/represent it any way they want. The way they’re represented has no real relationship to when sequence numbers need to reset. TradeDate and other date only fields left in FIX 4.0 represent a logical trading date (i.e. date of the local market) and are the ones which would be used for “end of trading day” processing.
The real challenge is for firms who support trading activity in the North and South America, Europe, and Pacific Rim (and any other market that doesn’t include) since you are potentially dealing with three distinct trading “days” and there is no “best” time to go down and reset sequence numbers and then reconnect later. It may make sense for
counterparties to establish 3 different FIX Sessions (with more than one running concurrently for certain periods of time) to accomodate different world markets and any end of day batch processing associated with each, for example. I think everyone will implement solutions which best fit their technical and business requirements.
[ original email was from Jeremy Fitzhardinge - ]
> I don’t see a need for fields to specify the timezone for
> timestamps in the FIX spec. All timestamps are specified
> in GMT and (in FIX 4.0) include the date so it’s pretty
> easy for systems to convert/represent it any way they
> want.
I suspect the FIX 4.0 spec. is in error when it talks about GMT. GMT is the local time of the UK (&c), and is subject to daylight saving/summer time shifts. UTC is the name of the base timezone from which others are measured (so GMT is UTC+1 at the moment, I think).
I’m seeing problems in my FIX implementation because time fields in messages are shifting about by an hour depending on what time of year it is.
Jeremy Fitzhardinge
Softway Pty. Ltd.
[ original email was from scott_atwell@americancentury.com - ]
> > I don’t see a need for fields to specify the timezone for
> > timestamps in the FIX spec. All timestamps are specified
> > in GMT and (in FIX 4.0) include the date so it’s pretty
> > easy for systems to convert/represent it any way they
> > want.
>
> I suspect the FIX 4.0 spec. is in error when it talks about GMT. GMT is the local time of the UK (&c), and is subject to daylight saving/summer time shifts. UTC is the name of the base timezone from which others are measured (so GMT is UTC+1 at the moment, I think).
>
> I’m seeing problems in my FIX implementation because time fields in messages are shifting about by an hour depending on what time of year it is.
>
> Jeremy Fitzhardinge
> Softway Pty. Ltd.
>
You are correct that the “official” name for the base timezone is now UTC (Coordinated Universal Time or Universal Time Coordinated ), however, “GMT” is effectively the same time and has historically been the term/method used. It is not subject to DST. The fact that a specific locale observes daylight savings time causes it’s local time to be +/- an hour. You shouldn’t be off an hour.
Please refer to:
http://www.boulder.nist.gov/timefreq/glossary.htm
Which states:
Coordinated Universal Time or Universal Time Coordinated (UTC): A coordinated time scale, maintained by the Bureau International des Poids et Mesures (BIPM), which forms the basis of a coordinated dissemination of standard frequencies and time signals. NOTE: A UTC clock has the same rate as a Temps Atomique International (TAI) clock or international atomic time clock but differs by an integral number of seconds called leap seconds. The UTC scale is adjusted by the insertion or deletion of seconds (positive or negative leap seconds) to ensure approximate agreement with UT1 (also known as the Julian Date).
Greenwich Mean Time (GMT): A 24 Hour system based on mean Solar time plus 12 hours at Greenwich, England. Greenwich Mean Time can be considered approximately equivalent to Coordinated Universal Time (UTC), which is broadcast from all standard time and frequency radio stations. However, GMT is now obsolete and has been replaced by UTC.
You can also refer to:
http://www.greenwich2000.com/time/timezone.htm
and
http://www.yahoo.com/science/weights_and_measures/measurements/time/
Hope that helps.
Scott Atwell
American Century