I just discovered an issue with how TimeUUIDs are compared in Cassandra that was affecting pycassa and probably affects other clients.
To allow for easy slicing of rows with TimeUUIDType comparators, pycassa lets you supply a timestamp for the column start and end. To make sure that all columns within that time range were collected, regardless of the random portions of the UUIDs, I was filling the non-timestamp bytes with 0x00 bytes or 0xff bytes to make the lowest or highest possible TimeUUID, respectively, with the same timestamp. It turns out that the comparison that Cassandra does to break ties when the timestamp components match performs a signed byte comparison on each byte. This means 0x00 is not the lowest possible value, 0x80 is. Likewise, 0x7f is the actual highest byte value, not 0xff. So, if your client does something similar, this commit may be a useful reference for you in order to get the correct behavior: https://github.com/pycassa/pycassa/commit/7df88df4b533c193f029834541be16ff2e4b75f5 -- Tyler Hobbs DataStax <http://datastax.com/>
