4 ms·

> Because 1ms "that sounds kinda good enough :?" Ugh. You wouldn't think so, but I caught a case of this in production, using millisecond timestamps as unique

by dkarl 6y ago

> Because 1ms "that sounds kinda good enough :?" Ugh. You wouldn't think so, but I caught a case of this in production, using millisecond timestamps as unique ids for browser analytics. The developer felt that even though two users could in rare cases click at exactly the same millisecond, their clocks weren't likely to be in perfect sync with each other, and that this "additional level" of randomness made a collision virtually impossible.

Quekid5 6y ago
Oh dear god. I suppose it can be counter-intuitive, but people really need to learn about timer precision... and, more importantly, statistics (basics, at least!). I absolutely hate the 'combinatorics' part of statistics, but distributions, etc. seemed pretty learnable to me... but then I like continuous math, so...
- j-pb 6y ago
  That's not even statistics. That's simply the pigeon hole principle. A second has 1000ms. If you have more than 1000 users doing things per second, there MUST be a collision.
  - Quekid5 6y ago
    Ah, but now you're discretizing! :D ... also, it Technically depends on your throughput (something something queue theory).
  - Can_Not 6y ago
    Then you have https://en.m.wikipedia.org/wiki/Birthday_problem https://en.m.wikipedia.org/wiki/Birthday_problem Even with a small number of users per second (like 20) it becomes likely to happen often.
mywittyname 6y ago
I worked on an analytics system where we appended a random 3 digits to the millisecond resolution timestamp for exactly this reason. It turns out, collisions are far, far more common that the math would suggest. Especially back in the aughts when browser had a lot of individual quirks to deal with.
XCSme 6y ago
> even though two users could in rare cases click at exactly the same millisecond, their clocks weren't likely to be in perfect sync with each other, and that this "additional level" of randomness made a collision virtually impossible I think that the clocks not being in sync doesn't increase randomness in any way, as two clients who didn't click at the same time might still get the same value.
- saagarjha 6y ago
  And you'd be right.

by dkarl 6y ago

Quekid5 6y ago

Oh dear god. I suppose it can be counter-intuitive, but people really need to learn about timer precision... and, more importantly, statistics (basics, at least!). I absolutely hate the 'combinatorics' part of statistics, but distributions, etc. seemed pretty learnable to me... but then I like continuous math, so...

j-pb 6y ago
That's not even statistics. That's simply the pigeon hole principle. A second has 1000ms. If you have more than 1000 users doing things per second, there MUST be a collision.
- Quekid5 6y ago
  Ah, but now you're discretizing! :D ... also, it Technically depends on your throughput (something something queue theory).
- Can_Not 6y ago
  Then you have https://en.m.wikipedia.org/wiki/Birthday_problem https://en.m.wikipedia.org/wiki/Birthday_problem Even with a small number of users per second (like 20) it becomes likely to happen often.

mywittyname 6y ago

I worked on an analytics system where we appended a random 3 digits to the millisecond resolution timestamp for exactly this reason. It turns out, collisions are far, far more common that the math would suggest. Especially back in the aughts when browser had a lot of individual quirks to deal with.

XCSme 6y ago

> even though two users could in rare cases click at exactly the same millisecond, their clocks weren't likely to be in perfect sync with each other, and that this "additional level" of randomness made a collision virtually impossible I think that the clocks not being in sync doesn't increase randomness in any way, as two clients who didn't click at the same time might still get the same value.

saagarjha 6y ago
And you'd be right.