[
https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14135921#comment-14135921
]
Joshua McKenzie commented on CASSANDRA-7523:
--------------------------------------------
Pushed an updated branch.
{quote}You should use TimeUnit.HOURS etc instead of creating static variables
and multiplying by them (incl millisPerDay){quote}
Updated to use TimeUnit enum. Much cleaner abstraction - thanks for pointing
that out.
{quote}Why getMillisAtMidnight()? Doesn't seem to be used, but uses
Calendar{quote}
calendar threadlocal and that method were vestigial from some other interim
work and I overlooked that while reviewing - I've removed it.
{quote}It would be nice to make these values byte-order comparable up front,
although we can take care of it as part of the later work to be able to
transform all bytes to such representations.{quote}
Since the discussion is still ongoing and we don't know what form things are
going to stabilize in, I'd prefer to keep the complexity of dealing with /
preparing for a constraint of byte-order comparability in a separate effort.
This also helps keep the code-base consistent as we won't have some types that
are refactored to support different storage constraints, some that aren't.
{quote}Do we need to support "empty" values on new types? seems to me we could
explicitly forbid them, or would thrift clients still expect to be able to set
this to empty? What's to stop is introducing semantics for new types that
prevent this, so we can start stamping it out?{quote}
Good question. I went with an implementation that was consistent with the rest
of the code-base but can see the argument either way.
> add date and time types
> -----------------------
>
> Key: CASSANDRA-7523
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7523
> Project: Cassandra
> Issue Type: New Feature
> Components: API
> Reporter: Jonathan Ellis
> Assignee: Joshua McKenzie
> Priority: Minor
> Fix For: 2.1.1, 3.0
>
>
> http://www.postgresql.org/docs/9.1/static/datatype-datetime.html
> (we already have timestamp; interval is out of scope for now, and see
> CASSANDRA-6350 for discussion on timestamp-with-time-zone. but date/time
> should be pretty easy to add.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
