BTP GeneralizedTime's Leap-second should be "smeared"

[sappenin]

In IL-RFC-30, the spec mandates that the String value of a leap-second date should BTP-encode to a String that matches its ISO-8601 counterpart (i.e., keep the leap second in each String), like this:

2016-12-31T23.59.60.852Z -> 20161231235960.852Z (leap second)

However, I suggest that the RFC should instead specify that leap-second dates should simply be invalid. As an example, it's unlikely that a system would produce a Timestamp like this: 2016-12-31T23.59.60.852Z

My rationale is as follows:

1. Object Construction in JS & Java

• Both modern-Java (see Instant.java) and Javascript (see here) "smear" leap seconds into the broader day that includes a leap second. Thus, neither platform actually ever represents a leap-second, but instead smears a portion of the leap-second into the existing seconds of the day, so a day always has 86400 seconds.
• As an example, doing the following in JS produces a Date that does not contain the leap-second:

new Date('Dec 31 2016 23:59:60 UTC')
Sat, 31 Dec 2016 23:59:00 GMT

2. Parsing

• Parsing a leap-second value does not work by default in Java, nor in Javascript. For example, see this JSFiddle here where constructing a new Date with the String 2016-12-31T23:59:60.852Z produces an error.
• Likewise in Java, Instant.parse("2016-12-31T23:59:60.852Z") throws an exception.
• Also, it's likely that btp-packet is actually broken in this regard when handling leap-seconds per this code here.

3. UTC Standards

• This above "smearing" or "smoothing" is actually a UTC standard. See UTC-SLS.

[adrianhopebailie]

Makes sense to me.

@justmoon @emschwartz WDYT? If I recall correctly the choice to use ISO-8601 was to explicitly support leap seconds however I'm not sure if we checked at that time if any OS parsers actually support leap seconds when parsing ISO 8601 format strings like those shown in the examples.

As a side note, I think that section of the IL RFC 30 is out of date as ILP packets no longer use ASN.1 GeneralizedTime.

[justmoon]

@sappenin Makes sense to me, this was an oversight on my part. Thanks for noticing and the quality research.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is important, please feel free to bring it up on the next Interledger Community Group Call or in the Gitter chat.