TODO: Determine value of valueOf

[mattjohnsonpint]

We should decide what .toString() and .valueOf() return for each object type. We should also consider the output of console.log for each object type, and whether it is the same or different than the toString output.

[domenic]

FYI console.log output is not something for specs to decide; it's for individual devtools teams to work through in order to create a UI they feel is best for their users.

[mattjohnsonpint]

Good to know. Though I must say, it's such a P.I.T.A. of a problem today when the toString output doesn't match the console log output. For example:

console.log(new Date());

// Chrome:
//=> Sat Jul 08 2017 16:18:31 GMT-0700 (Pacific Daylight Time)

// FireFox:
//=> Date 2017-07-08T23:18:31.674Z

Chrome output matches toString, but FF matches toISOString with "Date" preceding.

I suppose there's nothing we can do in this spec to deal with that, but it does come up again and again on StackOverflow. Was hoping to at least have a suggested output format for implementers. Would that be allowed?

[domenic]

Maybe as part of https://console.spec.whatwg.org/ , but definitely not as part of ECMAScript.

[mattjohnsonpint]

Yep. this exactly. Thanks for the link. :)

Ok, so ignoring the console log output, the rest of this issue still stands.

[maggiepint]

I'm most concerned about valueOf on ZonedInstant. Is the same instant in two different zones comparable? This is probably the hardest hurdle here.

[mattjohnsonpint]

@maggiepint - good point. Need to think about that one more...

[mattjohnsonpint]

To add here: @domenic noted in #35 that Array.prototype.sort uses toString, not valueOf. So let's be sure any toString output is lexicographically sortable. Sticking with ISO8601 will help.

[apaprocki]

@maggiepint In our datetime classes, we resisted providing comparison/equality operators that implicitly convert to help avoid human error. The programmer has to explicitly write what they want. It would be akin to requiring something like this:

Verify two zoned instants refer to the same point in UTC:

if (newYorkZonedInstant.toUTC() == tokyoZonedInstant.toUTC()) ...
// 2017-07-11T09:00:00-04:00       2017-07-11T21:00:00+08:00
// v                               v
// 2017-07-11T13:00:00          == 2017-07-11T13:00:00
// true

Verify the local plain datetimes are the same / throw away the offset/zone:

if (newYorkZonedInstant.toPlain() == tokyoZonedInstant.toPlain()) ...
// 2017-07-11T09:00:00-04:00         2017-07-11T21:00:00+08:00
// v                                 v
// 2017-07-11T09:00:00            == 2017-07-11T21:00:00
// false

(We opted to make both functions return the equivalent of PlainDateTime)

[gilmoreorless]

It would also be good to define what the JSON output should be for each type. Date explicitly defines .toJSON() to return the output of .toISOString() (spec).
I'm assuming that for the temporal objects the JSON output would be the same as .toString() (that is, ISO 8601 as mentioned by @mj1856 above), but it should still be explicitly stated.

[mattjohnsonpint]

Decided in #74 that we will not have a valueOf function, so closing this issue.