[
https://issues.apache.org/jira/browse/CASSANDRA-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16609039#comment-16609039
]
Benedict commented on CASSANDRA-14708:
--------------------------------------
{quote}I'll also note this all went in C* 3.10, so it's not like we can really
change the goals of the duration type
{quote}
We can at least revisit if it turns out to not make enough sense, and I'm not
sure that it does. Do you have a link to the original discussions around its
inclusion, because it seems to treat the concept of durations in a confusing
manner. At the very least, if it's accepting {{months}} and {{days}} as
parameters, it should be accepting {{hours}}, and {{seconds}} because these are
not occupy a consistent number of nanos across all points in time. Typically,
a time library will offer facilities to work exclusively in millis/nanos, or in
all date components, not mix the two half-heartedly.
This has me generally worried about how we handle time in Cassandra.
> protocol v5 duration wire format is overly complex and awkward to implement
> for clients
> ---------------------------------------------------------------------------------------
>
> Key: CASSANDRA-14708
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14708
> Project: Cassandra
> Issue Type: Bug
> Reporter: Chris Bannister
> Priority: Major
>
> Protocol V5 defines the duration type to be on the wire as months, days and
> nanoseconds. Days and months require a timezone to make sense of the duration
> and varies depending on from which they are applied for.
>
> Go defines a [duration|https://golang.org/pkg/time/#Duration] type as
> nanoseconds in int64 which can represent ~290 years. Java
> [duration|https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html]
> does not have way to handle months.
>
> I suggest that before 4.0 is release the duration format is converted to just
> be represented as nanoseconds.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
