Comments (13)
I revised the doc with @bradleypeabody's suggestion:
ietf-wg-uuidrev/rfc4122bis@4405609
I have not made the second change for "or time intervals close to milliseconds" will let the discussion here play out.
PR closes Friday on draft-11 to ensure we make the scheduled telechat date next week.
from uuid6-ietf-draft.
@sergeyprokhorenko Thanks for the feedback.
I would like to leave it at this (with the most recent change above that Kyzer did) since we've addressed the original concern. As a general concept, I'd like to just leave it saying "milliseconds" wherever possible (i.e. let's not introduce this other "or time intervals close to milliseconds"). The spec is specifically milliseconds, and think we've sufficiently covered the idea that if you put something else in there that isn't exactly milliseconds then the time will be off if it's parsed by some other UUID parser, but that's a totally acceptable tradeoff for implementations that don't care about timestamp interoperability. IMO we've covered it well enough at this point.
from uuid6-ietf-draft.
Would it be better to put:
"such as dividing a microsecond (or a number of microseconds) by 1024..." just to cover both.
from uuid6-ietf-draft.
Would it be better to put:
"such as dividing a microsecond (or a number of microseconds) by 1024..." just to cover both.
I don't think so. After all, if you divide a microsecond by 1000, you get a nanosecond.
from uuid6-ietf-draft.
[...] if you divide a microsecond by 1000, you get a nanosecond.
I thought you multiply a Microsecond to get a Nanosecond? Else, the last part of the sentence is also wrong...
- https://www.inchcalculator.com/convert/microsecond-to-millisecond/
- https://www.inchcalculator.com/convert/microsecond-to-nanosecond/
But that aside, my point in adding both was you could theoretically convert 1µs or 2µs+ by 1000 or 1024 to get some form of MS/NS.
By adding both to the verbiage we cover one or more µs to MS conversion (normally or by odd intervals).
from uuid6-ietf-draft.
Is it correct to use a number of nanoseconds in UUID v7? (Obviously, that would require +20 bits in timestamp section)
If this is valid, I think, wording "such as dividing a microsecond (or a number of microseconds) by 1024..." is most precise IMV.
from uuid6-ietf-draft.
Is it correct to use a number of nanoseconds in UUID v7?
It is not correct (see 6.2. Monotonicity and Counters):
Replace Left-Most Random Bits with Increased Clock Precision (Method 3):
For UUIDv7, which has millisecond timestamp precision, it is possible to use additional clock precision available on the system to substitute for up to 12 random bits immediately following the timestamp
The accuracy of the timestamp has been limited on purpose after much discussion: #23 (comment)
6.1. Timestamp Considerations:
With UUID version 1 and 6, 100-nanoseconds of precision are present while UUIDv7 features millisecond level of precision by default within the Unix epoch that does not exceed the granularity capable in most modern systems
Also, it's pointless to make the timestamp more accurate (nanoseconds) than the time source (microseconds)
from uuid6-ietf-draft.
My 2c here is that we should either leave the text how it is (just because we're very close to getting this thing finally published), or if we change anything my suggestion would be to go back to not having that text about dividing by 1024 at all. The spec already says there are no guarantees about the accuracy of the timestamp, and it's up to the implementation to determine how far off from the original value they want to make it. Dividing by 1024 gives a decidedly "incorrect" value (off by months if not years depending on the timestamp), but since there's no guarantee, it's still technically allowed. But I do not think we should encourage it.
Anyway, I just don't think trying to carefully fiddle with that text to take other edge cases into account is worth holding up the document for.
from uuid6-ietf-draft.
@sergeyprokhorenko Just so we understand, what was the intention of the original question - what problem were you trying to solve with this:
Is it possible to change
"such as dividing a microsecond by 1024 (or some other value) instead of 1000 to obtain a millisecond value"
for
"such as dividing a number of microseconds by 1024 (or some other value) instead of 1000 to obtain a millisecond value"?
from uuid6-ietf-draft.
You haven't given any convincing arguments. We still have time to correct the error in the text.
The time source gives us the number of microseconds. To get the number of milliseconds for UUIDv7, they need to be divided by 1000. But the approximate division by 1024 takes much less computational resources. There is no point in exact division by 1000. This is a problem that absolutely all implementations face. Therefore, we cannot ignore it, as you suggest.
Why it was proposed to divide some one microsecond by 1024, I cannot explain, because this is an erroneous phrase.
from uuid6-ietf-draft.
@sergeyprokhorenko Thanks and understood. Until that last message I didn't get what error in the text was that you're referring to (you suggested a change but didn't clearly say why). But okay, I think I get it now: Your concern is that dividing microseconds by 1024 doesn't yield milliseconds, it yields . Is that correct?
If so, I guess we could change the sequence of that text to make it read more correctly like so. As suggested text to give the whole thing:
Implementations MAY alter the actual timestamp. Some examples include security considerations around providing a real clock value within a UUID, to correct inaccurate clocks, to handle leap seconds, or instead of dividing a number of microseconds by 1000 to obtain a millisecond value, diving by 1024 (or some other value) for performance reasons. This specification makes no requirement or guarantee about how close the clock value needs to be to the actual time.
If we're going to leave in this 1024 text, then that would be my suggestion (assuming I understand the concern correctly.)
That said, I still don't understand how suggesting the user divide by 1024 is helpful at all. The rest of the specification clearly says milliseconds (and changing text above here doesn't change that), so if you're dividing by 1024 you're ignoring the rest of the spec. And, that's okay, it's allowed as mentioned earlier because there are no guarantees on the accuracy of the timestamp. But I still don't see any reason to suggest to implementors to do this 1024 division since it's clearly not what anything else in the document says to do. So I'm not going to die over it, but it really seems like it would be better to just take this 1024 text out entirely. You can still do whatever you want, not having this text doesn't prevent that, but it would prevent the kind of confusion generated as we can see in this discussion.
Everyone who reads this and does the math is going to go "uhm, if we divide by 1024 then it's not milliseconds, why is it telling me to do that?"
from uuid6-ietf-draft.
Your new wording is perfect:
Implementations MAY alter the actual timestamp. Some examples include security considerations around providing a real clock value within a UUID, to correct inaccurate clocks, to handle leap seconds, or instead of dividing a number of microseconds by 1000 to obtain a millisecond value, dividing by 1024 (or some other value) for performance reasons. This specification makes no requirement or guarantee about how close the clock value needs to be to the actual time.
I agree with you that the spec should be internally consistent. Therefore, I propose to expand the wording:
UUIDv7 values are created by allocating a Unix timestamp in milliseconds, or time intervals close to milliseconds, in the most significant 48 bits and filling the remaining 74 bits, excluding the required version and variant bits, with random bits for each new UUIDv7 generated to provide uniqueness as per Section 6.8.
It's only important that it's not days or microseconds: #23 (comment)
from uuid6-ietf-draft.
diving
It is typo. Should be dividing
from uuid6-ietf-draft.
Related Issues (20)
- The conditions for the use of source-generated UUIDs and receiver-generated UUIDs HOT 3
- Provide a complete UUIDv8 example
- Encouraging the use of UUID as the primary key HOT 8
- Fork safety HOT 1
- Fix RFC4086 link in Normative References
- Draft 04: MUST to SHOULD to reduce "absolute monotonicity" requirements
- Tout est Terrible. Endian problems with original RFC 4122 + case problems HOT 8
- Draft 05: B.2. Example of a UUIDv7 Value two "var" in table
- Draft 05: MUST veribage in Reliability of 6.1
- Announcement: Post-IETF 114 and the future of this Draft HOT 26
- Typo in UUIDv7 example value HOT 1
- Remove "time-based" constraint from version 8 UUID HOT 1
- Further clarify v7 field description HOT 3
- Required UUIDv7 generator features for RDBMS (PostgreSQL etc.)
- Approximate UUID timestamp calculations HOT 24
- Performance testing for UUIDv7 HOT 14
- RDBMS and other platforms that support UUIDv7
- UUIDv7 logo HOT 20
- Reserving a special form within UUIDv10 (alternating UUID) HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from uuid6-ietf-draft.