FpML Issues Tracker
closed
Minor
Always
Schema
Admin
mgratacos
Summary
All,
We have a simple type that we use for exercise times called HourMinuteTime
Shouldnt this type allow the support for time offsets (i.e. +00:00)?
closed
Minor
Always
Schema
Admin
mgratacos
All,
We have a simple type that we use for exercise times called HourMinuteTime
Shouldnt this type allow the support for time offsets (i.e. +00:00)?
Notes:
mgratacos
07/25/07 9:30 am
According to the FpML Architecture it should; and we should follow the Architecture.
Matthew
mgratacos
07/25/07 9:38 am
I propose to amend the simple type to allow a time offset:
Let me know if there is any objection to this.
Kind regards,
Marc
mgratacos
07/26/07 7:15 am
The purpose of the pattern is constrain the seconds value to “:00”. In the
absence of a documented rationale, I guess the author either overlooked or
disregarded the optional time zone indicator. Presumably this has not been
raised as an issue until now, because the only instance of the type occurs
in association with a businessCenter (within type BusinessCenterTime),
which implicitly localises the time.
Where the time zone indicator is produced, it must be consistent with the
quoted businessCenter – does this imply the need for a validation rule
(easy to express in conceptual terms, harder to implement)?
NB: if we permit timezone offsets, we also have to support the UTC
indicator (“Z” suffix).
Best regards,
Harry
mgratacos
07/26/07 7:16 am
Harry,
To implement this rule we’d need an external source with business centers and their corresponding time offsets. I am not sure how practical that is in terms of implementation.
Wouldn’t be much simpler in terms of processing to rely on explicit offsets (and maybe enforce its use in this case) instead of business centers? Obviously, implemented in version 5.0. Then, the question is whether we allow both in the 4.x versions.
Thanks,
-Marc
mgratacos
07/26/07 7:16 am
Offsets are not timezones. Any offset can legally be used for any timezone.
Matthew
mgratacos
07/26/07 7:17 am
Marc,
Please see my responses (HMcA>) below.
Best regards,
Harry
Harry,
To implement this rule we’d need an external source with business centers
and their corresponding time offsets. I am not sure how practical that is
in terms of implementation.
HMcA> That’s what I meant by “harder to implement”
Wouldn’t be much simpler in terms of processing to rely on explicit offsets
(and maybe enforce its use in this case) instead of business centers?
Obviously, implemented in version 5.0. Then, the question is whether we
allow both in the 4.x versions.
HMcA> Simpler to process perhaps – but if we replace businessCenter with a
timezone offset, we lose information present in the legal documentation
e.g. an exercise time expressed in the confirm as “09:00 a.m. London time”.
I’m not sure if this is acceptable.
mgratacos
07/26/07 7:17 am
Must be a slow morning …
The W3C recommendation on date/time representation is based on ISO 8601,
which provides for times expressed either in UTC, or in local time with a
time zone offset relative to UTC. There are no local timezone designators
as such. In this sense, offsets and timezones are equivalent, because the
offset in a dateTime expression is *always* relative to UTC.
From the specification*:
3.2.7.3 Timezones
Timezones are durations with (integer-valued) hour and minute properties
(with the hour magnitude limited to at most 14, and the minute magnitude
limited to at most 59, except that if the hour magnitude is 14, the minute
value must be 0); they may be both positive or both negative.
The lexical representation of a timezone is a string of the form: ((‘+’ |
‘-‘) hh ‘:’ mm) | ‘Z’, where
hh is a two-digit numeral (with leading zeros as required) that
represents the hours,
mm is a two-digit numeral that represents the minutes,
‘+’ indicates a nonnegative duration,
‘-‘ indicates a nonpositive duration.
The mapping so defined is one-to-one, except that ‘+00:00’, ‘-00:00’, and
‘Z’ all represent the same zero-length duration timezone, UTC; ‘Z’ is its
canonical representation.
When a timezone is added to a UTC dateTime, the result is the date and time
“in that timezone”. For example, 2002-10-10T12:00:00+05:00 is
2002-10-10T07:00:00Z and 2002-10-10T00:00:00+05:00 is 2002-10-09T19:00:00Z.
– I think that’s clear enough.
Best regards,
Harry
(*W3C Recommendation 28 October 2004, XML Schema Part 2: Datatypes Second
Edition)
mgratacos
07/26/07 7:18 am
Harry,
I don’t see why we lose information. The information may be represented in a different format but I think it’s the same.
10:00:00 ESMA = 10:00:00+01:00
As I understood, Business Centers were applied to check calendars and roll dates for holidays. I don’t think they should be used to define a time zone.
mgratacos
07/26/07 7:18 am
I see your point that it needs to be checked from a legal side though.
mgratacos
07/26/07 7:19 am
Yes: the problem is not with the designation of the instant-of-time, but
the identification of the location as per the relevant ISDA matrix (many
locations may share the same timezone).
HMcA
mgratacos
07/26/07 7:19 am
Marc,
there is another dependency. If you start using business centres to
drive time zones, and do it consistently across the standard, then you
will have to put in business centres in adjustable dates even if no
business day convention applies – and that breaks our validation rules.
Alternatively, you lose consistency by making exceptions for certain
locations in FpML.
Regards,
Christian
mgratacos
07/26/07 7:19 am
>> I guess the author either overlooked or disregarded the optional time
zone indicator
When the type was designed the corresponding time element would always
have been used with a corresponding business center as Harry mentioned.
This has always been the case in Rates. So for example, an expiration
time may be defined as 11:00 New York time so the time would be
specified as 11:00:00 and then the corresponding business center element
would contain USNY. I don’t think allowing a timezone offset in these
cases would be particularly helpful or desirable. Since specifying a
time with a time zone offset doesn’t actually define which centre the
time is applicable to and also won’t take into account daylight savings
etc. since the offset will always be relative to GMT.
Guy