cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <>
Subject Re: Standardizing Timestamps Across Clients
Date Sat, 20 Mar 2010 22:51:01 GMT
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.)


On Thu, Mar 18, 2010 at 3:37 PM, Jeff Hodges <> 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 <> 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

View raw message