Looks like consensus is that "microseconds since epoch" is the way to go. I've updated the cli to do this. (Will be in the release after 0.6 beta3.)
-Jonathan On Thu, Mar 18, 2010 at 3:37 PM, Jeff Hodges <jhod...@twitter.com> wrote: > As one of the committers to cassandra.gem, microseconds is the way to > go. Specificity is nice to have when you haven't been thinking about > timestamps and suddenly have a deep, abiding need to care about them. > > I cannot understate that. It is much easier to remove the specificity > than it is to put it in after the fact. > -- > Jeff > > On Thu, Mar 18, 2010 at 12:36 AM, Jonathan Hseu <vom...@vomjom.net> wrote: >> Jonathan Ellis suggested that I bring this issue to the dev mailing list: >> >> Cassandra should recommended a default timestamp across all clients >> libraries. >> >> Many users on IRC are having difficulty when using different clients because >> different clients are using different timestamps. If you insert with one >> client, you may not be able to modify the key later with another. The >> Cassandra website doesn't seem to mention timestamps much, so users get >> confused when operations fail on certain clients. >> >> Here's what different clients are using: >> >> 1. Cassandra CLI: Milliseconds since UTC epoch. >> 2. lazyboy: Seconds since UTC epoch. It used to be seconds since local time >> epoch. Now it's changing again to microseconds since UTC epoch. >> 3. driftx's client: Milliseconds since UTC epoch. >> 4. The example app, Twissandra: Microseconds since UTC epoch. >> 5. pycassa: Microseconds since UTC epoch. It used to be seconds since local >> time epoch. >> 6. The most popular Cassandra Ruby client: Microseconds since UTC epoch. >> >> Here's why the default recommended timestamp should be microseconds since >> UTC epoch: >> >> 1. It allows backwards-compatibility. Some people are already using >> microseconds, so if it suddenly switched to milliseconds, all the timestamps >> would be smaller, and they'd be unable to insert or remove existing columns. >> Microsecond timestamps would always be greater than millisecond timestamps, >> so new operations would work. >> 2. There exist reasons people would want to use microseconds over >> milliseconds (finer granularity), but I don't think there are any reasons >> one would prefer milliseconds over microseconds. >> >> 3 (just for me). I just changed pycassa to microseconds, and I'd hate to >> change it again :( >> >> >> Jonathan Hseu >> >
