incubator-cassandra-dev mailing list archives

Just a note for PHP users that using microtimes with the
thrift_protocol module won't work on 32-bit machines
(https://issues.apache.org/jira/browse/THRIFT-729).
.michael.
On Sun, Mar 21, 2010 at 8:51 AM, Jonathan Ellis <jbellis@gmail.com> wrote:
> 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
>>>
>>