Should Cassandra respect the order of a timeuuid clustering key?

Question

Is the following behavior by the cassandra:4.1.3 Docker container expected (in which the second-listed c_key is less than the first)?

cassandra@cqlsh> describe table foobars.foobars;

CREATE TABLE foobars.foobars (
    pkey timeuuid,
    w_ckey text,
    c_ckey timeuuid,
    bar text,
    foo uuid,
    PRIMARY KEY (pkey, w_ckey, c_ckey)
) WITH CLUSTERING ORDER BY (w_ckey ASC, c_ckey ASC)
    AND additional_write_policy = '99p'
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND cdc = false
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '16', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND memtable = 'default'
    AND crc_check_chance = 1.0
    AND default_time_to_live = 0
    AND extensions = {}
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair = 'BLOCKING'
    AND speculative_retry = '99p';
cassandra@cqlsh> select * from foobars.foobars where pkey = b98fea01-9b8b-11ee-9e71-937c45431a90 and w_ckey = 'foobar 2';

 pkey                                 | w_ckey   | c_ckey                               | bar | foo
--------------------------------------+----------+--------------------------------------+-----+--------------------------------------
 b98fea01-9b8b-11ee-9e71-937c45431a90 | foobar 2 | b98fea00-9b8b-11ee-9e71-937c4543ffff | bar | b9a21270-9b8b-11ee-9e71-937c45431a90
 b98fea01-9b8b-11ee-9e71-937c45431a90 | foobar 2 | b98fea00-9b8b-11ee-9e71-937c45431fff | bar | b99c6d20-9b8b-11ee-9e71-937c45431a90

(2 rows)

I created two rows (via Mapper). I expected the row with the lower-valued timeuuid final clustering key to be listed before the higher valued. (The represented bits are either identical or clearly greater where one has an F and the other doesn't.) Both Mapper and cqlsh report rows in what seems to be a random fashion; sometimes the order is as expected and sometimes it isn't.

Answer 1

Never mind; it makes sense to ignore the non-time-bearing part of the timeuuid for clustering-column ordering.