Formalize log format of Date objects

[mattjohnsonpint]

var d = new Date();
console.log(d);

Output in some implementations is equal to the result of d.toISOString(), while in other implementations it is equal to the result of d.toString(). This poses a problem because while .toISOString() uses a standardized format (ISO-8601), it also displays the UTC-equivalent time - whereas .toString() displays the local time.

d.toString()    //=> 'Mon Apr 02 2018 15:22:45 GMT-0700 (Pacific Daylight Time)'
d.toISOString() //=> '2018-04-02T22:22:45.686Z'

While this distinction is easy to see when explicitly calling one of those two functions, it is much harder to understand when just calling console.log(d). This leads to tons of questions on sites like StackOverflow where new developers are confused because they don't understand that there's an implicit string conversion going on, and one that's implementation specific (example here).

It would be really useful if this standard could formalize this (preferably on the toISOString output, IMHO), such that eventually all implementations could return the same results.

Thanks.

[terinjokes]

If the logged Date object is matched with the "%s" format specifier the behavior is defined: ToString(element), which ends up calling toString() on Date objects.

If logged Date object is not matched with a format specifier, it, like every other object, becomes implementation defined and possibility interactive. Implementers are welcome to comment otherwise, but I don't see this changing.

[domfarolino]

Indeed. Ultimately we're just logging an object here, with no conversions or specifiers applied. This defers to the Printer abstract op defined in the spec which gives implementers a lot of freedom to display things to a user.

As Terin mentioned, if some sort of conversion were done here, we could specify it (or use some conversion algorithm already specified in for example, the ECMAScript Specification), so I'm going to close this for now since the actual display of an object is implementation-defined.

---

I appreciate you opening the issue though and if you have any other feedback or concerns please let us know!

[mattjohnsonpint]

I understand that it's just printing an object. However, since Date is a built-in "standard object" in ECMAScript (aka "global object"), wouldn't it make sense for Printer to define some guidelines for how these objects are to be displayed?

[terinjokes]

What makes sense in one context, such as the Node.js console, does not necessarily make sense in another, potentially interactive, context, like the browser developer tools.

If this was something observable from scripts, then I'd have a different tune. As it stands, you're effectively throwing data over a wall: it's up to the other side to determine how, and when, to display that. This could be a localized string, a "time ago" string, an ISO8601 timestamp, or a calendar widget, depending on what they felt was the best for the developers using their tool.

[domfarolino]

I definitely understand the want for that sorta thing, but typically the Printer is used to display an object with basically no conversions or tidying-up done (often this is just displaying it as a tree structure sort of laying out the object's properties + methods + prototype chain etc). How would one get this view of an object if Printer always cleaned up the output (by doing some sort of conversion or deference to ECMAScript spec) before displaying?