[
https://issues.apache.org/jira/browse/CASSANDRA-11873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15334073#comment-15334073
]
Tyler Hobbs commented on CASSANDRA-11873:
-----------------------------------------
This is a good point to take a step back and plan out the semantics of our date
and time types more thoroughly. I don't think we need to implement everything
up front, but we should think about how we want the various date, time, and
interval types to work together.
We do not currently support a datetime type with timezones. However, it's
certainly possible that this may be added in the future, especially if we focus
on timeseries (where you may want rollups by conceptual day instead of 24 hour
periods). So, I think we should consider how the types might interact with a
timezone-aware datetime.
The current {{duration}} type is similar to Java's {{Duration}} and Python's
{{timedelta}}. It adds a number of nanoseconds to a datetime, ignoring effects
like daylight savings time. On the other hand, we may also want something like
Java's {{Period}} class, which works in terms of "conceptual" days, months and
years. For example, if you add a conceptual day to a datetime and it happens
to cross the daylight savings time boundary, it would end up at the same time
of day on the next day (instead of being off by one hour, like the equivalent
{{duration}} addition would be).
Or, we might combine these into an interval type like Postgres's {{interval}}
that stores conceptual months and days, but also stores seconds and
nanoseconds. This could work in a pretty straightfoward way with our current
timestamps (effectively UTC datetimes), but also work well with timezone-aware
datetimes when those are added. This type is certainly more complex than the
current {{duration}} type, but I think we'll eventually need something like
this anyway, and it's good to ask whether we also want to have a naive
{{duration}} alongside that type. If we introduce special syntax for
{{duration}}, that may force future {{interval}} literals to have a more
cumbersome syntax. At the very least, the differences between the two may
confuse users.
To summarize, if we want to plan for the future, it may be best to go ahead and
implement a full {{interval}} type now that handles conceptual time units as
well as raw seconds/nanoseconds.
bq. By consequence, it can be difficult for the driver to handle such a type.
I don't think that this should weigh heavily on how we design Cassandra's
types. We are already forced to implement custom types in several of the
drivers. For example, the python driver has custom classes for {{OrderedMap}},
{{SortedSet}}, {{Time}}, and {{Date}} to handle things like nested collections
and nanosecond resolution. These are slightly less friendly for users than
types in the standard library, but it's fairly normal for a database driver to
need to do this.
> Add duration type
> -----------------
>
> Key: CASSANDRA-11873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11873
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
> Reporter: Benjamin Lerer
> Assignee: Benjamin Lerer
> Labels: client-impacting, doc-impacting
> Fix For: 3.x
>
>
> For CASSANDRA-11871 or to allow queries with {{WHERE}} clause like:
> {{... WHERE reading_time < now() - 2h}}, we need to support some duration
> type.
> In my opinion, it should be represented internally as a number of
> microseconds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
