The timestamp of a column is an arbitrary version number, the value of which is determined by the client that created the column. It's merely convention (and convenience) that clients use the current timestamp. Since the timestamp is a client-concern, and in non-trivial topologies Cassandra may not be running on the application nodes, it makes no sense to include this functionality in Cassandra.
TL;DR: See Gary's message. On 17 June 2011 16:09, Tim Wisniewski <tjw3...@gmail.com> wrote: > It makes the overall system more bullet proof > > On Fri, Jun 17, 2011 at 11:01 AM, Tim Wisniewski <tjw3...@gmail.com> > wrote: > > > it's slightly less burden on the user > > > > > > On Fri, Jun 17, 2011 at 11:00 AM, Gary Dusbabek <gdusba...@gmail.com > >wrote: > > > >> That problem is already solved externally. I don't see the value of > >> reimplementing it inside of cassandra. > >> > >> Gary. > >> > >> On Fri, Jun 17, 2011 at 09:58, Tim Wisniewski <tjw3...@gmail.com> > wrote: > >> > Hi, > >> > > >> > My understanding is data corruption can occur if the node clocks are > too > >> far > >> > out of sync. What if Cassandra nodes maintained an internal time sync > >> via > >> > ntp or something? > >> > > >> > -Tim > >> > > >> > > > > >
