Date.prototype.toString is defined in a very strange way. I think the intention of the method is to be generic and use NaN as a time-value for non date objects.
However Step 1. "Let O be this Date object." doesn't really make sense in connection with Step 2., because only Date objects would have a [[DateValue]].
My suggestion:
1. Let O be the this value.
2. If Type(O) is not Object, throw a TypeError exception.
and like before:
3. If O does not have a [[DateValue]] internal slot, then
...
Note: This function is intentionally generic.
If the function should _not_ be generic then current Step 2. makes no sense to me.
See the text in 20.3.4 that defines specification conventions that are specific to Date.prototype methods:
In following descriptions of functions that are properties of the Date prototype object, the phrase “this Date object” refers to the object that is the this value for the invocation of the function. If the Type of the this value is not Object, a TypeError exception is thrown.
That section also says "Unless explicitly defined otherwise, the methods of the Date prototype object defined below are not generic" ... Anyway using prose that does those not very obvious things is not very nice to the reader.
fixed in rev39 publication draft
Added a NOTE stating that Date.prototype.toString is "intentionally generic".
Phrases like "this Date object" and "this time value" that carry non-obvious semantics are a legacy of the ES3 spec. Replacing them with something more explicit is too large a change to make at this point in the ES6 publication process. Feel free to file a ES7 bug suggesting replacement of all such phrases.