This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6343 - [FO] op:gYearMonth-equal
Summary: [FO] op:gYearMonth-equal
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 minor
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-03 13:02 UTC by Michael Kay
Modified: 2012-03-29 08:07 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2009-01-03 13:02:30 UTC
The function op:gYearMonth-equal (10.4.15) states in the text that it compares the "starting instants" of the two months, but what it actually does is to compare the starting instant of the last day of each month. This does not give an incorrect result, but it leads to a rather confusing description. 

The first example makes this worse by applying the rules incorrectly: it tells us that the starting instant of 1976-02 is 1972-02-29T00:00:00!

The corresponding text for op:gYear-equal uses the first day of the month rather than the last, which seems more straightforward.
Comment 1 Michael Kay 2009-01-03 13:23:54 UTC
Also affects op:gMonth-equal()
Comment 2 Michael Kay 2009-01-06 16:51:58 UTC
Noted that this text in the intro to 10.4 is also relevant: The starting instant of an occurrence of a date/time value is an xs:dateTime calculated by filling in the missing components of the local value from a reference xs:dateTime. If the value filled in for a missing day component exceeds the maximum day value for the month, the last day of the month is used. Suppose, for example, that the reference xs:dateTime is 1972-12-31T00:00:00
Comment 3 Michael Kay 2009-02-23 15:06:45 UTC
I think that there are three possible approaches to resolving this.

(a) use a term other than "starting instant", for example "reference instant"

(b) change the reference date/time so that it is indeed the starting instant. As far as I can tell, the only reason we choose 1972-12-31 is because the day contains a leap second and the year contains a leap day. We no longer support leap seconds, so 1972-01-01 would work just as well, and we would then be comparing the starting instants of a gYearMonth or gYear as we claim to do.

(c) continue to use the term "starting instant" and continue to use the reference date 1972-12-31, and use some weasel words to explain that when we say "starting instant" we don't really mean it.

I'm inclined to do (c) for an erratum / 3rd edition (the change is too late for the 2nd ed.), and to do (b) for F+O 1.1.

Comment 4 Michael Kay 2009-05-26 13:50:16 UTC
For F+O 1.1, I have changed the text to use approach (b), that is, to use 1972-01-01 as the starting instant.

Still needs to be fixed for 1.0.
Comment 5 Michael Kay 2009-06-16 15:45:16 UTC
Reclassified as editorial for the time being. Will draft an erratum for the "1.0" spec in due course.
Comment 6 Michael Kay 2012-03-29 08:07:06 UTC
This is now on the list of candidate errata for the 1.0/2.0 specification, so I am marking it as resolved/closed.