Add a way to extract the generated timestamp from Guids created with CreateVersion7()

[QuantumToasted]

As a person who used Medo.Uuid7 in the past for a project, I like the idea of a simple, time-sortable, timestamp-embedded unique ID type (sometimes referred to as a snowflake). When I heard .NET was getting its own implementation of UUIDv7 in Guid, I was looking forward to ditching dependencies on third-party libraries when I could use something in the BCL. Finding out that pretty much all we got was Guid.CreateVersion7() with no extra fanfare or features felt...a little underwhelming.

Given that Guid.CreateVersion7() shoves the bytes for the timestamp into an already-generated Guid, would it be possible to reverse this process via a static method on Guid?

I'd propose something like the following in Guid.cs:

public static DateTimeOffset ExtractVersion7Timestamp(Guid guid)
{
    if (guid.Version != 7)
        throw new InvalidOperationException("Only version 7 Guids are supported.");
    
    var timestamp = // extract the timestamp bytes...
    return timestamp;
}

As someone who felt disappointed that UUIDv7's useful features (sortable, embedded [extractable!] timestamp, unique* ID) were only partially implemented in the BCL (the first and third), I think that this is a useful addition and I'm surprised that it wasn't considered or added from the beginning.

[danmoseley]

I see that package says

Conversion from and to System.Guid; it's faster to create Uuid7 and convert it to Guid than using Guid.CreateVersion7() on its own.

Is that inevitable? I wonder if it deserves an issue

[tannergooding]

A lot of the perf differences comes from things like the .NET implementation ensuring that a cryptographically secure RNG is used for filling in the unused bits of the UUIDv7.

However, the relevant APIs for a user to build their own Guid creation functions that provide the raw bits all exist and there's no need to provide a custom data structure for that. They can freely generate whatever 128-bits they need and pass it into the new Guid(...) constructor.

There's been a handful of issues around UUIDv7 that have discussed these topics more in depth, the considerations the .NET Libraries needs to take into account, potential future extensibility options we could provide, and some sample data showing the number of UUIDs you'd need to generate for the performance difference to actually be meaningful (which is unlikely considering most such UUIDs are being inserted into some database).

[tannergooding]

I covered a lot of the reason that such a property or method wasn't exposed under #107136 (comment)

Namely that the format itself is intentionally flexible and there is no definitive way to know how much the GUID actually needs to be extracted, how much is random, how much could be extended time-stamp data, etc.

This is very unique to the scenario in question and would require a quite complex and not very efficient API, which would be better handled by a custom extension method instead. That then also doesn't need to consider the behavior of what happens if the input isn't a UUIDv7 and if it were instead a UUIDv4, for example.

[indy-singh]

I'm surprised this isn't offered on the API; for those who arrived via Google like me. I ended up with this:-

public static DateTimeOffset ExtractTimestampFromGuidV7(Guid guid)
{
  var guidString = guid.ToString("N");
  var timestampHex = guidString.Substring(0, 12);
  var timestampValue = Convert.ToInt64(timestampHex, 16);
  return DateTimeOffset.FromUnixTimeMilliseconds(timestampValue);
}

Usually caveats apply, I haven't written it for performance, no error handling. It's the bare bones basic implementation to get the information we need.

Cheers,
Indy