ISO 8601 duration panics when fractional part present

[toptobes]

When inserting a duration such as '1ns', the Data API returns the following duration: 'PT0.000000001S'

However, if you try to turn around and insert that duration back into the Data API, it starts shaking and crying in the corner:

> await table.insertOne({ text: '1', int: 1, duration: 'PT0.000000001S' })
Uncaught:
DataAPIResponseError: Only values that are supported by the column data type can be included when inserting a document into a table.

The table default_keyspace.test_table defines the columns: text(text), int(int), ..., duration(duration), ....
The command included the following columns that had invalid values: duration: Error trying to convert to targetCQLType `DURATION` from value.class `java.lang.String`, value "PT0.000000001S". Root cause: Invalid String value for type `DURATION`; problem: Unable to convert 'PT0.000000001S' to a duration.

Resend the command using only supported column values.

[toptobes]

Also, the error message for max # of nanoseconds is incorrect:

The total number of nanoseconds must be less or equal to 2147483647

This should be Long.MAX_VALUE instead.

[hemidactylus]

(to the first point, we had discussed the matter in a meeting on Nov 12 (api+client teams) and it was remarked that the fix for the fractional seconds in the ISO format was going to extend beyond just the API code so it would not be a quick thing. Meanwhile, the suggested route is to always use C* format in writes and always expect ISO format in reads. Ref.)

[amorton]

@toptobes can you please include the full error object in the ticket please

[amorton]

However, if you try to turn around and insert that duration back into the Data API, it starts shaking and crying in the corner:

@toptobes This is NOT a good bug report, can you please try explain clearly:

• The request you sent
• The response you got back
• The expected response

[amorton]

Over to @tatu-at-datastax for checking for duplicate

[tatu-at-datastax]

I think I understand the problem wrt call, codec failure (although ideally request/response would be included).

This seems like a duplicate of #1626.