The basic one is that with any mechanism that has random numbers at its core, there is no guarantee of uniqueness, despite what Data::UUID POD says. (If you look up the RFC it uses the phrase: "is either guaranteed to be different from all other UUIDs/GUIDs generated until 3400 A.D. or extremely likely to be different".

The probability of collision might be very small, but it still exists. It would therefore be necessary to record enough information to disambiguate between chance collisions. And that means recording all the information that went into generating the number in the first place. As I wouldn't have access to all the information, that isn't possible.

A second reason is that the timestamping mechanisms used by Data::UUID are broken.

1. On Windows: It uses QueryPerformanceCounter() api to get a timestamp to the required 100 nanosecond resolution.

   But this high resolution elapsed time counter is known to drift with respect to the system clock, but the module make no attempt at corrections.

   See Time::HiRes for its correction mechanism.

2. On other systems: it uses GetSystemTime(2).

   But that api is limited to microsecond resolution, so it just multiplies by 10.

While the spec calls for a once-only randomly initialised, thereafter monotically increasing, sequence component, I can see no provision for storing/retrieving this on windows systems.

The output of the true_random() function is suspect on systems where rand()is limited to 15 bits.

As my needs are limited to a single system, using a deterministic value with a self-consistent, high resolution time component will suffice.