+dateString:isEqualToDateString:

[boredzo]

This class method would parse two ISO 8601 date strings and return whether they are equal.

Matters for debate:

• Should the parsing be strict?
• How exact should the comparison be? (Ideal, I suppose, would be detect how much information is in each string—e.g., whether one omits seconds—and accept equality within that level of granularity.)
• What options, if any, should be provided for customization of the comparison? (E.g., whether parsing is strict or not.)

[carllindberg]

You could pass in an NSCalendarUnit mask to specify the portions to compare. If not provided, maybe the granularity is based on whatever the strings have -- if there is a granularity mismatch, maybe they are not equal. Another possibility is to return an NSComparisonResult instead of BOOL, making it more of a compare method. I guess another question is what are you more interested in comparing -- the individual date units in the string, or the dates they represent? What would you want to do if the hour or even day is different, and the time zone is different, but the two represent the same second, just in different time zones?

[boredzo]

I view comparison of individual components as a job for NSDateComponents.

Time zones are a good point. I think I was probably only thinking of things like comparing “-8-30T17:41:58+0000” to “2013-08-30T17:41:58Z”, but I think it's reasonable that if the specified time zones are different, that that difference should be accounted for.

I'm not sure how the opposite would even work. Would two strings that specify different time zones simply be inequal?

Whether time zones are accounted for or not, I thought of another question: What should happen if only one string specifies a time zone? Assume UTC? Use/compare to the other string's TZ? Something else?

[carllindberg]

OK, makes some sense, just comparing the string portions. If you are going by that, typically an "isEqual" method is pretty strict. So in that case, I'd probably require the same components -- i.e. something with just an hour and minute would not be equal to something with an hour, minute, and second. The former could be a duration of the entire minute, or something like that -- from what I've read I think ISO8601 leaves some interpretation to the particular usages. Likewise, if the values of any component are different (even time zones, other than 0000 vs Z), I'd probably say the strings are not equal.

I was not even aware you could omit the year -- wouldn't that be required always? I think RFC 3339 always does, though that is just a subset. Or is that for use in a duration, i.e. -8-30-T17:41 represents a duration of 8 months, 30 days, 17 minutes, and 41 seconds? Otherwise, just assuming a "current year" might depend on current time zone, as well -- not sure that is unambiguous and not sure I'd consider it equal to an explicit year provided.

I'm not sure of the exact use case you had in mind, but for a bare "isEqual" method, I'd probably lean towards being strict. I suppose you could have another method (with another name, or an options: parameter maybe) which might allow comparison of just the common provided components, provided one is a superset of the other -- that would be a little bit looser.

[boredzo]

Re: first paragraph, what if two date strings are equal if one falls within the other? E.g., 2013-09-05T22:59:05 is within (and thus “equal” to) 2013-09-05T22:59.

Year and month can be omitted in any ISO 8601 date. I'm specifically referring to absolute dates, rather than intervals, since the ISO 8601 Date Formatter currently only supports the former. As I remember, missing components are inferred from the current date (or other contextually relevant base date); today being September 5th, “--07” is two days from now (September 7th), and “-08-05” is a month ago.

[carllindberg]

Not sure if "within" really means "equal". For example, Java's BigDecimal, the numbers 5.00 and 5.0000 (the same numeric values), will return false from equals() (since the precisions are different) even though compareTo() will return 0 (numerically equal). An NSSet which is a superset of another NSSet will not be "equal" (they have isSubsetOfSet: for that comparison). Two NSStrings, one of which contains 0x00C0 (capital A with grave accent), and another which contains the composed character sequence 0x0041 0x0300 (capital A followed by a grave accent combining mark), will return NO from isEqual: (since their literal values are different) but will return NSOrderedSame from compare: (since they are equivalent sequences per the Unicode specification). Unless of course you pass NSLiteralSearch to compare:options: anyways ;-)

I'm not saying that a comparison method that returns YES for two ISO8601 specifications where one "contains" the other would not be useful -- it might be more useful in practice than a strict comparison, for all I know -- but usually the term "isEqual" in a method name implies the more strict comparisons.

If 2013-09-05T22:59 is equal to 2013-09-05T22:59:05, and it is also equal to 2013-09-05T22:59:37, then from a certain perspective you might expect 2013-09-05T22:59:05 to be equal to 2013-09-05T22:59:37, but I'm guessing they would not be.

For the example without a year specified, one of them requires interpretation against the current year or some other context, and one of them does not, so it would not seem as though those were "equal". They would only be equal if their context was the same, and I'm not sure the method can assume the context (unless passed in a base NSDateComponents which has the values to fill in with). For example, if you use a value of -01-01T03:00:00, and you run your comparison in the UK, you might get a different result for "current year" than if you run it in the eastern US at the same moment (say comparing against a current-time string of "2014-01-01T03:00:00"). A method which performs that comparison using the current time in the local time zone as its assumed context may be the most useful one to have, but I'm not sure I'd use "isEqual" in the name if that's what you are after.