The value of "uniqueid" can clash much faster than expected

[CJDennis]

uniqueid only has a range of 16 bits (65536 different values). There is a ~50% chance of at least one clash after only 301 values have been generated (assuming the random numbers are statistically random). See https://math.stackexchange.com/q/2066675/187345. The name of the variable is very misleading because it does nothing to guarantee that each value is unique, it just hopes for the best.

[stefangabos]

Well, I really don't think you should have that many datepickers on a page, but suggestions are welcome

[CJDennis]

At work, we can have four date fields per row and 50 rows per screen. That's a total of 200 datepickers in an extreme case. That has a 26.3% chance of a collision. After 4 pages, there's a 70.5% chance that a collision happened at least once. After ten people have viewed 4 pages each, it's practically guaranteed that a collision has occurred for at least one of them at 99.9995% chance.

Why is the variable called unique when it's random? Is it important for it to be random or is being unique more important? What's wrong with starting at 1? If there has to be some random element, why not use a static variable to set an initial value and increment it each time? Perhaps you should separate that bit of code into its own function (get_unique_id() or get_random_id(), etc.), then you can change just that function without looking like you're changing the other one. There should be something about the formula used or the function that guarantees that collisions can't happen.

[stefangabos]

Is this satisfactory for your use-case?