When you generate a UUID in 4D using the Generate UUID command, you might encounter results like:

9c8f7b2a-d134-bf47-912e-4c62a1b58d31

At first glance, it may look incorrect, especially if you're familiar with version 4 UUIDs as defined by RFC 4122, where the third block is expected to start with a 4 (indicating the version). But here, it starts with bf.

No need to worry—the UUID is still valid and fully RFC 4122–compliant.

This quirk comes from how UUIDs are represented on Windows. 4D uses native OS functions like UuidCreate to generate UUIDs. These functions return the UUID as raw bytes in little-endian order. When 4D formats these bytes into a string, it doesn’t adjust the byte order, so the version nibble appears to be “out of place.” Specifically, the version nibble shows up at the 15th character instead of the 13th, due to this byte-ordering difference.

So while it may look different, it’s technically sound.