41–48 of 48 posts
I'm curious why they specify the UUID must have dashes in string format. It makes the UUID difficult to select with a double click.
you do understand that they existed way before the mouse and button became the norm ?
Not sure when the "doucle-click to select" UI paradigm became common though.
I'm curious why they specify the UUID must have dashes in string format. It makes the UUID difficult to select with a double click.
Earlier quoted context omitted.
That’s the normal way IETF RFCs describe unix seconds since the epoch, though there ought to be a normative reference to https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
The problem with "seconds since the Epoch" is that if you naively add milliseconds, it is no longer monotonic. Since 2016-12-31T23:59:60Z is 1483228800 seconds since the Epoch, and 2017-01-01T00:00:00Z is also 1483228800 seconds since the Epoch, that means that 2016-12-21T23:59:60. xxx Z would have the same timestamp as 2017-01-01T00:00:00. xxx Z, for all xxx . This corresponds to the counter jumping backward 1000 mi…
The key here is that I use "seconds" to mean a fixed duration of time, like how long it takes light to travel 299792458 meters in a vacuum[1], and this version of seconds is independent of Earth orbiting the Sun, or the Earth spinning or anything like that[2]. If I understand you correctly, you use "seconds" more akin to how I use "days in a year": Most years have 365 days, but when certain dates starts to drift too far from some astronomical phenomenon we like to be aligned with (e.g. that the Northern Hemisphere has Summer Solstice around the 21st of June) we insert an extra day in some years (about every 4th year).
I haven't read RFC 9562 in detail, but if you use my version of "seconds" then "seconds since the Epoch" is a meaningful and monotonically increasing sequence. I suspect that some of the other commentors in this thread use this version of "seconds" and that some of the confusion/disagreement stems from this difference in definition.
The paragraph in Section 6.1 titled "Altering, Fuzzing, or Smearing" also seems relevant:
> Implementations MAY alter the actual timestamp. Some examples include ..., 2) handle leap seconds ...
> This specification makes no requirement or guarantee about how close the clock value needs to be to the actual time.
[1] I know that the SI definition between meters and seconds is the other way around, but I think my point is clearer this way.
[2] I ignore relativity as I don't think it is relevant here.
I'm curious why they specify the UUID must have dashes in string format. It makes the UUID difficult to select with a double click.
Earlier quoted context omitted.
The problem with "seconds since the Epoch" is that if you naively add milliseconds, it is no longer monotonic. Since 2016-12-31T23:59:60Z is 1483228800 seconds since the Epoch, and 2017-01-01T00:00:00Z is also 1483228800 seconds since the Epoch, that means that 2016-12-21T23:59:60. xxx Z would have the same timestamp as 2017-01-01T00:00:00. xxx Z, for all xxx . This corresponds to the counter jumping backward 1000 mi…
I would say that the instance (or second long interval) in time that we name 2016-12-31T23:59:60Z is 1483228836 seconds after 1970-01-01T00:00:00Z, and that 2017-01-01T00:00:00Z is 1483228837 seconds after 1970-01-01T00:00:00Z [0]. The key here is that I use "seconds" to mean a fixed duration of time, like how long it takes light to travel 299792458 meters in a vacuum[1], and this version of seconds is independent of…
But Unix time isn't a count of SI seconds, as you might wish it to be. Instead, it's effectively "the number of whole days between 1970-01-01 and UTC-today, times 86400, plus the number of SI seconds since the last UTC-midnight." It smashes each UTC day into 86400 'seconds', regardless of whether it is truly longer or shorter due to leap seconds. This makes Unix time non-monotonic at the end of a leap second, since it rolls back that second at the following midnight.
It's nice that the RFC mentions leap seconds at all, but it's really playing with fire to leave it so vague, when monotonicity is an especially important property for these UUIDs. Its brief definition of the UUIDv7 time source as "the number of milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded" especially doesn't help here, because the discrepancies in UTC are even worse than leap seconds:
> I would say that the instance (or second long interval) in time that we name 2016-12-31T23:59:60Z is 1483228836 seconds after 1970-01-01T00:00:00Z, and that 2017-01-01T00:00:00Z is 1483228837 seconds after 1970-01-01T00:00:00Z [0].
Before 1972, the length of a UTC second was shorter than the length of an SI second. If you account for that, 2016-12-31T23:59:60 UTC is ~1483228827.999918 SI seconds after 1970-01-01T00:00:00 UTC; and 2017-01-01T00:00:00 UTC is ~1483228828.999918 SI seconds after 1970-01-01T00:00:00 UTC. Meanwhile, the "Unix time" (POSIX's "seconds since the Epoch") is 1483228800 for both seconds. (At least, these SI-second intervals are based on the widespread TAI − UTC table [0]. Beware that this table is also inaccurate, in that it was constructed from an older EAL − UTC table using a constant offset, but EAL and TAI continue to run at a different rate due to relativistic effects [1]. Since 1977, EAL − TAI has grown to over 0.00108 SI seconds.)
> I suspect that some of the other commentors in this thread use this version of "seconds" and that some of the confusion/disagreement stems from this difference in definition.
I wish. But the RFC says "leap seconds excluded", and it's designed to align with "Unix time" (which jumps back after every leap second), so clearly it isn't a count of physical SI milliseconds. There's a trilemma here: you can't (a) lie about ("exclude") leap seconds, (b) keep monotonicity, and (c) maintain a constant length of the second, all at the same time; you have to pick two. You yourself would prefer (b) and (c), and POSIX mandates (a) and (c) for "Unix time". But UUIDv7, to align with "Unix time", really wants (a) and (b), which requires smearing, or halting the time scale, or some other dedicated mechanism. Yet the RFC is nearly silent on this.
[0] https://hpiers.obspm.fr/eop-pc/earthor/utc/TAI-UTC_tab.html
[1] https://webtai.bipm.org/ftp/pub/tai/other-products/ealtai/fe...
I'm curious why they specify the UUID must have dashes in string format. It makes the UUID difficult to select with a double click.
Earlier quoted context omitted.
True, as universally unique identifiers, 128 (less a few) bits is not enough. You're talking about humanity generating 505 exabytes per year of just UUIDs. That won't happen any time soon.
Of course it will: "The UUID generation algorithm described here supports very high allocation rates of 10 million per second per machine or more, if necessary, so that they could even be used as transaction IDs." This is the use case they had in mind when building this algorithm, and it would only take about 10k machines worldwide to reach the above levels.
There is a solution that doesn't require extending UUIDs (which has a storage cost everyone pays), which is to use a URI/URN instead of a UUID to provide a namespace. In practice this already occurs, except the namespace (scheme, path) containing the UUID is implicit, as it hasn't been named.
Earlier quoted context omitted.
At 2016-12-31T23:59:59.999Z, 1483228799.999 seconds had elapsed from the epoch, excluding leap seconds, according to "Unix epoch source time". At 2017-01-01T00:00:00.000Z, 1483228800.000 seconds had elapsed from the epoch, excluding leap seconds, according to "Unix epoch source time". Now, at 2016-12-31T23:59:60.500Z, how many seconds had elapsed from the epoch, exluding leap seconds? What about 2016-12-31T23:59:60.0…
You can use whatever solution you want - hold the timestamp, smear time, it's up to you. It's still monotonic, and uses the same epoch. You've still got 74 random bits.
"Whatever solution" I want? So… let's assume the programmer thinks "it's just POSIX time", they call their language of choice's "gimme POSIX time" function. This function, under default circumstances, is probably going to say "the leap second in POSIX time is also the last second of the day", i.e., it repeats the timestamp. Thus, it isn't monotonic.
(Which is the point of the parent comment…)