Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.6k
[Uid] Add microsecond precision to UUIDv7 and optimize on x64#60898
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation
alexandre-daubois left a comment• edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Works nicely! Could we have a test covering that UUIDv7 microseconds is actually stored on generation? Something like:
publicfunctiontestV7MicrosecondPrecision(){$testCases = ['1645557742.000001','1645557742.123456','1645557742.999999' ];foreach ($testCasesas$timeStr) {$timestamp = \DateTimeImmutable::createFromFormat('U.u',$timeStr);$uuidStr = UuidV7::generate($timestamp);$uuid = UuidV7::fromString($uuidStr);$expected =$timestamp->format('U.u');$actual =$uuid->getDateTime()->format('U.u');$this->assertSame($expected,$actual); }}
Thanks for the proposal, PR updated with a test case inspired from yours. |
fa8b32e intosymfony:7.4Uh oh!
There was an error while loading.Please reload this page.
This makes our implementation of UUIDv7 follow method 3 described by the RFC:
https://www.rfc-editor.org/rfc/rfc9562#section-6.2-5.6.1
UUIDv7 will now contain microsecond timestamp instead of just milliseconds.
This allows optimizing the code a bit, and I further optimized the x64 code path.
This makes the generation logic about 10% faster.