Why does PHPs uniqid function return only 13 digits and not 14?
uniqid() function returns a 13 digits long hexadecimal number. According to the spec in php.net site, the function uses microtime to generate the unique value.
But microtime returns numbers in string format as the following one:
"0.70352700 12689396875"
which are basically the microseconds and the seconds elapsed since 1970. This is a 9+11 digits decimal number.
Converting a 20 decimal number into hex would result in a 16 digits hexadecimal NOT a 13 digits one.
I also thought to take out the "0." part that seem to never change, and the last two digits of the microsec part that seem to remain always "00". Doing this the decimal number would be only 9+11-3 digits long, but still a decimal number of 17 digits when converted into hex would result in 14 digits hexadecimal number NOT 13.
I'M NOT INTERESTED IN GETTING A UNIQUE ID IN ANOTHER WAY OR A LONGER/SHORTER UNIQUE ID! I'M ONLY ASKING IF SOMEONE KNOWS WHY DOES uniqid RETURNS ONLY 13 DIGITS.
It seems nosense: if uniqid returns one digit less than microtime, it means that microtime gives out results that are more unique of the ones returned by uniqid.
Answer
Found this on http://www.php.net/manual/en/function.uniqid.php#95001
Makes sense to me. Comment if you need an explanation
For the record, the underlying function to uniqid() appears to be roughly as follows:
$m=microtime(true); sprintf("%8x%05x\n",floor($m),($m-floor($m))*1000000);
In other words, first 8 hex chars = Unixtime, last 5 hex chars = microseconds. This is why it has microsecond precision. Also, it provides a means by which to reverse-engineer the time when a uniqid was generated:
date("r",hexdec(substr(uniqid(),0,8)));
Increasingly as you go further down the string, the number becomes "more unique" over time, with the exception of digit 9, where numeral prevalence is 0..3>4>5..f, because of the difference between 10^6 and 16^5 (this is presumably true for the remaining digits as well but much less noticeable).