[jira] [Commented] (CASSANDRA-14708) protocol v5 duration wire format is overly complex and awkward to implement for clients
[ https://issues.apache.org/jira/browse/CASSANDRA-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16609073#comment-16609073 ] Benedict commented on CASSANDRA-14708: -- Thanks. It looks like we've at least introduced a bug wrt adding hours and seconds to a date/timestamp across leap second boundaries (and if we introduce TZ support, across DST boundaries), but that's an issue for another ticket. You brought up the issue of leap seconds in that discussion, I can see, so it's a shame this wasn't accounted for in the eventual solution. On the topic of this ticket, I agree that making the type accept nanos exclusively is not the solution; that is a different type of duration. It might have been nice to use the JDK or Joda time nomenclature for some consistency, and call it a period (and reserve duration for those operating exclusively on nanos/millis, much as in Go), but c'est la vie. > 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14708) protocol v5 duration wire format is overly complex and awkward to implement for clients
[ https://issues.apache.org/jira/browse/CASSANDRA-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16609045#comment-16609045 ] Sylvain Lebresne commented on CASSANDRA-14708: -- bq. Do you have a link to the original discussions around its inclusion Well, it's not exactly hard to find: CASSANDRA-11873. > 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14708) protocol v5 duration wire format is overly complex and awkward to implement for clients
[
https://issues.apache.org/jira/browse/CASSANDRA-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14708) protocol v5 duration wire format is overly complex and awkward to implement for clients
[
https://issues.apache.org/jira/browse/CASSANDRA-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608961#comment-16608961
]
Sylvain Lebresne commented on CASSANDRA-14708:
--
The duration time has been added primarily for doing aggregations over time,
and if you want to aggregate things by months, you don't want that to be all
messed up because you have to provide a time in nanoseconds which gives you no
way to get proper month boundaries. Overall, we cannot use nanoseconds for
duration in the way duration are currently implemented and used (including user
visible duration values like {{3m2d5s}}).
I just don't think our duration type and the similarly-named Golang one have
the same purpose. It might be a shame they have the same name, but well...
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 now even if we agreed this was a good idea (I
don't).
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
