[
https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14135807#comment-14135807
]
Benedict commented on CASSANDRA-7523:
-------------------------------------
A few quick comments:
* You should use TimeUnit.HOURS etc instead of creating static variables and
multiplying by them (incl millisPerDay)
* Why getMillisAtMidnight()? Doesn't seem to be used, but uses Calendar
* 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. But it would be preferable to make
this one byte-order comparable without conversion, since we have the
opportunity. This can be achieved with a simple offset, starting the minimum
value at 0, or shifting 0 to MIN_VALUE. i.e. add Integer/Long.MIN_VALUE to any
value you would currently generate.
* 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?
> 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)
