cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hseu <>
Subject Standardizing Timestamps Across Clients
Date Thu, 18 Mar 2010 07:36:35 GMT
Jonathan Ellis suggested that I bring this issue to the dev mailing list:

Cassandra should recommended a default timestamp across all clients

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message