In #54 it looks like it was decided that although we don't deal with leap seconds, parsing them would not be objectionable.

What about places like the DateTime constructor, that have a disambiguation argument? If you plug in the latest leap second:

• new Temporal.DateTime(2016, 12, 31, 23, 59, 60, 0, 0, 0, 'constrain') → 2016-12-31T23:59:59`
• new Temporal.DateTime(2016, 12, 31, 23, 59, 60, 0, 0, 0, 'balance') → 2017-01-01T00:00`
• new Temporal.DateTime(2016, 12, 31, 23, 59, 60, 0, 0, 0, 'reject') → 2016-12-31T23:59:60`
• for comparison: new Date(Date.UTC(2016, 12, 31, 23, 59, 60)) → 2017-02-01T00:00:00.000Z
• also for comparison: Temporal.DateTime.from('2016-12-31T23:59:60Z') → 2016-12-31T23:59:60
• and then this: Temporal.Absolute.from('2016-12-31T23:59:60Z') → 2017-01-01T00:00Z

The behaviour for constrain and balance seems as expected. But I think what happens in reject is a bit odd! I agree we should special-case it to not throw, since that might be a source of extremely rare and hard-to-track-down bugs in interoperability, but letting the :60 value stand seems incorrect as well, since we don't support leap seconds, so now we have an invalid DateTime object.

In addition, :60 is not rejected even if you tack it on to a minute in which a leap second can never occur, such as 16:01:60. (They occur at 23:59:60 UTC which can be any :59:60 and some :29:60 or :44:60 in other time zones.)

I'd propose that we silently convert :60 to :59 or :00 in reject mode and when parsing an ISO string, and document this behaviour. If that's too lenient, we could consider throwing if the time could not possibly be a leap second, like 16:01:60.