Converting a TimeUUID to a long (timestamp) and vice-versa

[Roshan Dawrani]

Hi,
I am having a little difficulty converting a time UUID to its timestamp equivalent and back. Can someone please help?

Here is what I am trying. Is it not the right way to do it?

===========================================================
        UUID someUUID = TimeUUIDUtils.getUniqueTimeUUIDinMillis();

        long time = someUUID.timestamp(); /* convery from UUID to a long timestamp */
        UUID otherUUID = TimeUUIDUtils.getTimeUUID(time); /* do the reverse and get back the UUID from timestamp */

        System.out.println(someUUID); /* someUUID and otherUUID should be same, but are different */
        System.out.println(otherUUID);
===========================================================

--
Roshan
Blog: http://roshandawrani.wordpress.com/
Twitter: @roshandawrani
Skype: roshandawrani

[Victor Kabdebon]

Hello Roshan,

Well it is normal to do not be able to get the exact same UUID from a timestamp, it is its purpose.

When you create an UUID you have in fact two information : random 64 bits number - 64 bits timestamp. You put that together and you have your uuid.

.

So unless you save your random number two UUID for the same milli( or micro) second are different.

Best regards,

Victor K.

http://www.voxnucleus.fr

2011/1/4 Roshan Dawrani <roshan...@gmail.com>

[Roshan Dawrani]

Hello Victor,

It is actually not that I need the 2 UUIDs to be exactly same - they need to be same timestamp wise.

So, what I need is to extract the timestamp portion from a time UUID (say, U1) and then later in the cycle, use the same long timestamp value to re-create a UUID (say, U2) that is equivalent of the previous one in terms of its timestamp portion - i.e., I should be able to give this U2 and filter the data from a column family - and it should be same as if I had used the original UUID U1.

Does it make any more sense than before? Any way I can do that?

rgds,
Roshan

[Patricio Echagüe]

In Hector framework, take a look at TimeUUIDUtils.java

You can create a UUID using   TimeUUIDUtils.getTimeUUID(long time); or TimeUUIDUtils.getTimeUUID(ClockResolution clock)

and later on, TimeUUIDUtils.getTimeFromUUID(..) or just UUID.timestamp();

There are some example in TimeUUIDUtilsTest.java

Let me know if it helps.

--
Patricio.-

[Victor Kabdebon]

Hi Roshan,

Sorry I misunderstood your problem.It is weird that it doesn't work, it works for me...

As Patricio pointed out use hector "standard" way of creating TimeUUID and tell us if it still doesn't work.
Maybe you can paste here some of the code you use to query your columns too.

Victor K.

http://www.voxnucleus.fr

2011/1/4 Patricio Echagüe <patr...@gmail.com>

[Roshan Dawrani]

Hi Victor / Patricio,

I have been using Hector library's TimeUUIDUtils. I also just looked at TimeUUIDUtilsTest also but didn't find anything similar being tested there.

Here is what I am trying and it's not working - I am creating a Time UUID, extracting its timestamp value and with that I create another Time UUID and I am expecting both time UUIDs to have the same timestamp() value - am I doing / expecting something wrong here?:

=======================================================
import java.util.UUID;
import me.prettyprint.cassandra.utils.TimeUUIDUtils;

public class TryHector {
    public static void main(String[] args) throws Exception {
        UUID someUUID = TimeUUIDUtils.getUniqueTimeUUIDinMillis();
        long timestamp1 = someUUID.timestamp();
       
        UUID otherUUID = TimeUUIDUtils.getTimeUUID(timestamp1);
        long timestamp2 = otherUUID.timestamp();
       
        System.out.println(timestamp1);
        System.out.println(timestamp2);
    }
}
=======================================================

I have to create the timestamp() equivalent of my time UUIDs so I can send it to my UI client, for which it will be simpler to compare "long" timestamp than comparing UUIDs. Then for the "long" timestamp chosen by the client, I need to re-create the equivalent time UUID and go and filter the data from Cassandra database.

--
Roshan
Blog: http://roshandawrani.wordpress.com/
Twitter: @roshandawrani
Skype: roshandawrani

[Roshan Dawrani]

If I use com.eaio.uuid.UUID directly, then I am able to do what I need (attached a Java program for the same), but unfortunately I need to deal with java.util.UUID in my application and I don't have its equivalent com.eaio.uuid.UUID at the point where I need the timestamp value.

Any suggestion on how I can achieve the equivalent using Hector library's TimeUUIDUtils?

[Roshan Dawrani]

Ok, found the solution - finally ! - by applying opposite of what createTime() does in TimeUUIDUtils. Ideally I would have preferred for this solution to come from Hector API, so I didn't have to be tied to the private createTime() implementation.

================================================================

import java.util.UUID;
import me.prettyprint.cassandra.utils.TimeUUIDUtils;

public class TryHector {
    public static void main(String[] args) throws Exception {

        final long NUM_100NS_INTERVALS_SINCE_UUID_EPOCH = 0x01b21dd213814000L;

        UUID u1 = TimeUUIDUtils.getUniqueTimeUUIDinMillis();
        final long t1 = u1.timestamp();

        long tmp = (t1 - NUM_100NS_INTERVALS_SINCE_UUID_EPOCH) / 10000;

        UUID u2 = TimeUUIDUtils.getTimeUUID(tmp);
        long t2 = u2.timestamp();

        System.out.println(u2.equals(u1));
        System.out.println(t2 == t1);
    }

}
 ================================================================

[Nate McCall]

It was our original intention on discussing this feature was to have
back-and-forth conversion from timestamps (we were modelling similar
functionality in Pycassa). It's lack of inclusion may have just been
an oversight. We will add this in Hector trunk shortly - thanks for
the complete code sample.

[Patricio Echagüe]

Roshan, just a comment in your solution. The time returned is not a simple long. It also contains some bits indicating the version. 

On the other hand, you are assuming that the same machine is processing your request and recreating a UUID base on a long you provide. The clockseqAndNode id will vary if another machine takes care of the request (referring to your use case) .

Is it possible for you to send the UUID to the view? I think that would be the correct behavior as a simple long does not contain enough information to recreate the original UUID.

Does it make sense? 

--
Patricio.-

[Roshan Dawrani]

Hi Patricio,

Thanks for your comment. Replying inline.

2011/1/5 Patricio Echagüe <patr...@gmail.com>

Roshan, just a comment in your solution. The time returned is not a simple long. It also contains some bits indicating the version. 

I don't think so. The version bits from the most significant 64 bits of the UUID are not used in creating timestamp() value. It uses only time_low, time_mid and time_hi fields of the UUID and not version, as documented here: http://download.oracle.com/javase/1.5.0/docs/api/java/util/UUID.html#timestamp%28%29.

When the same timestamp comes back and I call TimeUUIDUtils.getTimeUUID(tmp), it internally puts the version back in it and makes it a Time UUID.
 

On the other hand, you are assuming that the same machine is processing your request and recreating a UUID base on a long you provide. The clockseqAndNode id will vary if another machine takes care of the request (referring to your use case) .

When I recreate my UUID using the timestamp() value, my requirement is not to arrive at the exactly same UUID from which timestamp() was derived in the first place. I need a recreated UUID that should be equivalent in terms of its time value - so that filtering the time-sorted columns using this time UUID works fine. So, if the lower order 64 bits (clockseq + node) become different, I don't think it is of any concern because the UUID comparison first goes by most significant 64 bits, i.e. the time value and that should settle the time comparison in my use case.

Is it possible for you to send the UUID to the view? I think that would be the correct behavior as a simple long does not contain enough information to recreate the original UUID.

In my use case, the non-Java clients will be receiving a number of such UUIDs then and they will have to sort them chronologically. I wanted to avoid bits based UUID comparison in these clients. Long timestamp() value is perfect for such ordering of data elements and I send much lesser amount of data over the wire.
 

Does it make sense? 

Nearly everything makes sense to me :-)
 

--

[Patricio Echagüe]

Roshan, the first 64 bits does contain the version. The method UUID.timestamp() indeed takes it out before returning. You are right in that point. I based my comment on the UUID spec.

What I am not convinced is that the framework should provide support to create an almost identical UUID where only the timestamp is the same (between the two UUIDs).

UUID.equals() and UUID.compareTo() does compare the whole bit set to say that two objects are the same. It does compare the first 64 bits to avoid comparing the rest in case the most significant bits already show a difference.

But coming to your point, should Hector provide that kind of support or do you feel that the problem you have is specific to your application ?

I feel like UUID is as it says an Unique Identifier and creating a sort-of UUID based on a previous timestamp disregarding the least significant bits is not the right support Hector should expose.

Thoughts?

--
Patricio.-

[Roshan Dawrani]

Hi Patricio,

Some thoughts inline.

2011/1/6 Patricio Echagüe <patr...@gmail.com>

Roshan, the first 64 bits does contain the version. The method UUID.timestamp() indeed takes it out before returning. You are right in that point. I based my comment on the UUID spec.

I know 64 bits have the version, but timestamp() doesn't and hence it is OK to use it for chronological ordering. Anyway, we agree on it now and this point is out.
 

What I am not convinced is that the framework should provide support to create an almost identical UUID where only the timestamp is the same (between the two UUIDs).

Well, I didn't really ask for framework to provide me such an almost identical UUID. What I raised was that since Hector is computing UTC time in 100 nano-sec units as

utcTime = msec * 1000 + 0x01B21DD213814000L (NUM_100NS_INTERVALS_SINCE_UUID_EPOCH), it should, at the minimum, give a utility function to do the opposite

msec  =  (utcTime - 0x01B21DD213814000L / 1000), so that if someone has to create an almost identical UUID, where timestamp is same, as I needed, he shouldn't need to deal with such magic numbers that are linked to Hector's guts.

So, I don't mind creating the UUID myself, but I don't want to do magic calculations that should be done inside Hector to-and-fro, as it is an Hector's internal design thing.
 

UUID.equals() and UUID.compareTo() does compare the whole bit set to say that two objects are the same. It does compare the first 64 bits to avoid comparing the rest in case the most significant bits already show a difference.

I know it may need to look at all 128 bits eventually - but it first looks at first 64 bits (time stamp) and then the next 64. That's why I qualified it with "for my usecase". It works for me, because the data I am filtering is already within a particular user's data-set - and the possibility of a user having 2 data-points at the same nano-second value (so that clockseq+node bits come into picture) is functionally nil.
 

But coming to your point, should Hector provide that kind of support or do you feel that the problem you have is specific to your application ?

As covered above, half of my solution should go inside Hector API, I feel. Other half about re-creating the same-timestamp-UUID and comparison using it is specific to my application.
 

I feel like UUID is as it says an Unique Identifier and creating a sort-of UUID based on a previous timestamp disregarding the least significant bits is not the right support Hector should expose.

The support Hector should expose is to keep its magic calculations inside to-and-fro.

Does it make any sense?