incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
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.)

-Jonathan

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

Mime
View raw message