It's very unclear what you're asking. If you want the UTC date with the hours always 0, then set the UTC hours to 0 and use toISOString, e.g.

var d = new Date();
d.setUTCHours(0,0,0,0);
console.log(d.toISOString());

Of course this is going to show the UTC date, which may be different to the date on the system that generated the Date.

Also,

new Date('2017-04-27').toISOString();

should return 2017-04-27T00:00:00Z (i.e. it should be parsed as UTC according to ECMA-262, which is contrary to ISO 8601 which would treat it as local), however that is not reliable in all implementations in use.

If you just want to get the current date in ISO 8601 format, you can do:

if (!Date.prototype.toISODate) {
  Date.prototype.toISODate = function() {
    return this.getFullYear() + '-' +
           ('0'+ (this.getMonth()+1)).slice(-2) + '-' +
           ('0'+ this.getDate()).slice(-2);
  }
}

console.log(new Date().toISODate());

However, since the built-in toISOString uses UTC this might be confusing. If the UTC date is required, then:

if (!Date.prototype.toUTCDate) {
  Date.prototype.toUTCDate = function() {
    return this.getUTCFullYear() + '-' +
           ('0'+ (this.getUTCMonth()+1)).slice(-2) + '-' +
           ('0'+ this.getUTCDate()).slice(-2);
  }
}

console.log(new Date().toUTCDate());

Section 4.2.2 of ISO 8601 gives examples with no TZ designator saying they are local times. 4.2.4 says UTC times use the 'Z' designator. Of course it always raises the question "local time where?"...

The zone designator is empty if use is made of local time in accordance with 4.2.2.2 through 4.2.2.4, it is the UTC designator [Z] if use is made of UTC of day in accordance with 4.2.4 and it is the difference-component if use is made of local time and the difference from UTC in accordance with 4.2.5.2.

moment.js is great but sometimes you don't want to pull a large number of dependencies for simple things.

The following works as well:

    var tzoffset = (new Date()).getTimezoneOffset() * 60000; //offset in milliseconds
    var localISOTime = (new Date(Date.now() - tzoffset)).toISOString().slice(0, -1);
    
    console.log(localISOTime)  // => '2015-01-26T06:40:36.181'

The slice(0, -1) gets rid of the trailing Z which represents Zulu timezone and can be replaced by your own.

Here's a simple helper function that will format JS dates for you.

function toIsoString(date) {
  var tzo = -date.getTimezoneOffset(),
      dif = tzo >= 0 ? '+' : '-',
      pad = function(num) {
          return (num < 10 ? '0' : '') + num;
      };

  return date.getFullYear() +
      '-' + pad(date.getMonth() + 1) +
      '-' + pad(date.getDate()) +
      'T' + pad(date.getHours()) +
      ':' + pad(date.getMinutes()) +
      ':' + pad(date.getSeconds()) +
      dif + pad(Math.floor(Math.abs(tzo) / 60)) +
      ':' + pad(Math.abs(tzo) % 60);
}

var dt = new Date();
console.log(toIsoString(dt));

The option was introduced in the coreutils date (which is probably what you have) in 1999 (Apr. 8).

The documentation was removed in 2005 without much explanation in the commit.

In 2011, the help for --iso-8601 was reintroduced with the following explanation:

We deprecated and undocumented the --iso-8601 (-I) option mostly
because date could not parse that particular format.  Now that
it can, it's time to restore the documentation.
* src/date.c (usage): Document it.
* doc/coreutils.texi (Options for date): Reinstate documentation.
Reported by Hubert Depesz Lubaczewski in http://bugs.gnu.org/7444.

It looks like the help was taken out in version 5.90 and put back in, in version 8.15 (it is not in my 8.13) and the comment above suggests that it is now back to stay and not likely to be disappearing any time soon.

In version 8.31 (as provided by Solus July 2020) the man page has these two options:

   -I[FMT], --iso-8601[=FMT]
          output date/time in ISO 8601 format.  FMT='date' for date only (the default), 'hours', 'minutes', 'sec‐
          onds', or 'ns' for date and time to the indicated precision.  Example: 2006-08-14T02:34:56-06:00

   --rfc-3339=FMT
          output date/time in RFC 3339 format.  FMT='date', 'seconds', or 'ns' for date and time to the indicated
          precision.  Example: 2006-08-14 02:34:56-06:00

Update:

This is now covered by RFC 9557, which extends the original RFC 3339 by adding the time zone identifier in square brackets. For example:

2011-12-03T10:15:30+01:00[Europe/Paris]

Original Answer:

I understand these are not supported by ISO 8601, correct?

Correct. ISO-8601 does not concern itself with time zone identifiers. IANA/Olson TZ names are not a "standard". They are just the most reliable thing we have. (Some may consider them the de facto standard.)

What are platforms doing to support this?

Support what exactly? This part of your question is unclear. If you mean to support IANA time zones, well that's all over the place. Some platforms have them built-in, and some rely on libraries. If you mean to support a string representation of an ISO-8601 date-time-offset + time zone ID, some platforms have this and some do not. You'll have to be more specific if you want to know more.

I notice that the latest Java date/time library is using an extended ISO 8601 format for this, e.g. 2011-12-03T10:15:30+01:00[Europe/Paris]. (See DateTimeFormatter API.)

I think you are talking about DateTimeFormatter.ISO_ZONED_DATE_TIME. The docs say specifically:

The ISO-like date-time formatter...

...extends the ISO-8601 extended offset date-time format to add the time-zone. The section in square brackets is not part of the ISO-8601 standard.

So this is Java's specific format, not a standard.

Is there some converging convention (e.g. with other languages and platforms) for extending ISO 8601 to support time zone designation?

As far as I know, there is currently no standard that covers the combining of an ISO8601 timestamp and an IANA time zone identifier into a single format. One could represent it many different ways, including:

• 2011-12-03T10:15:30+01:00[Europe/Paris] (this is the default in Java 8)
• 2011-12-03T10:15:30+01:00(Europe/Paris)
• 2011-12-03T10:15:30+01:00 Europe/Paris
• 2011-12-03T10:15:30+01:00 - Europe/Paris
• 2011-12-03T10:15:30+01:00/Europe/Paris
• 2011-12-03T10:15:30+01:00|Europe/Paris
• 2011-12-03T10:15:30 Europe/Paris (+01) (this is the default in Noda Time)

If what you're looking for is a way to include a ZonedDateTime or similar data in an API in a standardized manner, my personal recommendation would be to pass the time zone name in a separate field. That way, each portion of data is as good as it can be. For example in JSON:

{
  "timestamp": "2011-12-03T10:15:30+01:00",
  "timezone": "Europe/Paris"
}

There is already a function called toISOString():

var date = new Date();
date.toISOString(); //"2011-12-19T15:28:46.493Z"

If, somehow, you're on a browser that doesn't support it, I've got you covered:

if (!Date.prototype.toISOString) {
  (function() {

    function pad(number) {
      var r = String(number);
      if (r.length === 1) {
        r = '0' + r;
      }
      return r;
    }

    Date.prototype.toISOString = function() {
      return this.getUTCFullYear() +
        '-' + pad(this.getUTCMonth() + 1) +
        '-' + pad(this.getUTCDate()) +
        'T' + pad(this.getUTCHours()) +
        ':' + pad(this.getUTCMinutes()) +
        ':' + pad(this.getUTCSeconds()) +
        '.' + String((this.getUTCMilliseconds() / 1000).toFixed(3)).slice(2, 5) +
        'Z';
    };

  }());
}

console.log(new Date().toISOString())

Simple way:

console.log( new Date().toISOString().split('.')[0]+"Z" );