FpML Issues Tracker
closed
Minor
N/A
Validation Rules
danieldui
danieldui
Summary
shared-27 currently reads as follows:
Context: Document (complex type) All timezones must be the same. +00:00, -00:00, and Z are considered equivalent.
Comment: This rule ensures that date and datetime comparisons behave as expected because they're expressed in the same timezone. NB That the XSD specification uses the term "timezone", but that they are not really timezones as they are fixed durations to represent time offsets. Subsequent to publishing XSD the W3C changed its position to clarify this: http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e226.
Andrew J noted that imposing all the dates in an instance document to use the same timezone may be too restrictive.
Should this rule be be changed to allow the use of multiple timezones in the same document?
Notes:
h_mcallister
08/31/10 5:07 pm
Either timezones are significant and consuming applications must be timezone-aware, or they are not significant and consuming applications can disregard them.
If the first case, then timezone-aware applications can be expected to honour timezone designations (i.e. timezone will be taken into account when performing operations such as date|dateTime comparisons), and the rule is redundant and potentially over-restrictive.
If the second case, then documents can safely be processed irrespective of timezone designations (i.e. as if all dates|dateTimes are in the same timezone), and the rule is redundant.
Take your pick.
mgratacos
09/17/10 3:16 pm
I think we should include both cases. Some firms don’t care about timezones while others are timezone-aware.
danieldui
09/21/10 11:44 am
Whatever the decision we should check the documentation and clarify the difference between time zones and time offset.
danieldui
10/02/10 7:24 pm
Issue was discussed on 21 Sep meeting.
We should go back to it when Andrew J, who raised the issue in the first place is present.
Daniel’s view is neutral:
On one hand there is probably not a good reason why all dates in an FpML document should use the same time offset.
On the other hand we don’t have a request from an implementer claiming that this rule is too restrictive.
lyteck
11/29/10 8:35 pm
Matthew Rawlings wrote Nov 24, 2010: [see original thread for full details – http://www.fpml.org/_wgmail/_validwgmail/msg01258.html%5D
“Dear VWG Members –
While updating my XQuery implementation of the validation rules I noticed something interesting. In the collateral rules, the rule col-5 depends on rule shared-27. Without shared-27, then col-5 may produce incorrect results.
col-5 (Mandatory)
English Description:
Context: interestCalculationDetails (complex type)
The value of each dailyInterestCalculation/calculationDate must be unique
XPath Description:
Context: interestCalculationDetails
count(distinct-values(dailyInterestCalculation/calculationDate)) eq count(dailyInterestCalculation/calculationDate)
…
shared-27 ensures the dates are reliably comparable, which col-5 needs to compare the dates to work out how many distinct values there are. Below is an XPath example that demonstrates which dates may be compared for XML Schema.
(: Returns a count of 1, because they’re equivalent 🙂
count(fn:distinct-values((xs:date(“2010-11-24”), xs:date(“2010-11-24”)))),
count(fn:distinct-values((xs:date(“2010-11-24Z”), xs:date(“2010-11-24”)))),
count(fn:distinct-values((xs:date(“2010-11-24Z”), xs:date(“2010-11-24Z”)))),
count(fn:distinct-values((xs:date(“2010-11-24+00:00”), xs:date(“2010-11-24”)))),
count(fn:distinct-values((xs:date(“2010-11-24+00:00”), xs:date(“2010-11-24+00:00”)))),
(: Returns a count of 2, because they’re inequivalent 🙂
count(fn:distinct-values((xs:date(“2010-11-24+01:00”), xs:date(“2010-11-24Z”)))),
count(fn:distinct-values((xs:date(“2010-11-24+01:00”), xs:date(“2010-11-24”)))),
count(fn:distinct-values((xs:date(“2010-11-24+01:00”), xs:date(“2010-11-24+00:00″))))
=> 1 1 1 1 1 2 2 2
There are other rules dependent upon shared-27, not just col-5. I raise the issue of col-5 because both col-5 and shared-27 are currently under discussion. Issues 1017 and 1018 propose discuss removing shared-27, yet at the same time we’d be adding col-5. We can’t do both. I propose leaving shared-27 and col-5 in place. The alternative is to remove shared-27, col-5, and all the other rules dependent upon shared-27.
Tony raised the issues. Tony, what do you think?
– Matthew”
matthew
12/01/10 10:06 pm
“Andrew J noted that imposing all the dates in an instance document to use the same timezone may be too restrictive.” – I completely agree. The original proposed formulation of this rule by myself was that dates must contain an explicit timezone, but that it may be any timezone. The current formulation of this rule was proposed by a long serving member of the VWG, and I was outvoted. It looks now as if the objections are withdrawn relaxing the rule to what was originally proposed: any timezone as a common reference point, but there must be a timezone, even if just UTC.
matthew
12/01/10 10:12 pm
The original issue is #126.
danieldui
05/16/11 3:05 pm
Meeting 2011-05-10:
The VWG confirms the decision taken in the past – The rule is to stay removed.
It’s OK to have a document where not all dates use timezones.
For example a document could omit time-zones in the main portion of the document, but use time-zones in the message header section of the document.
danieldui
05/16/11 3:06 pm
rule is to stay removed.