9 ms·

A somewhat oversimplified summary of the new UUID formats: UUID6: a timestamp with a weird epoch and 100 ns precision like in UUID1, but in a big-endian order

• deleted 5y ago
  [deleted]
• zvrba 5y ago
  > with a weird epoch and 100 ns precision Exactly as used by windows to store file times. And the epoch is the start of the modern calendar https://en.wikipedia.org/wiki/Gregorian_calendar https://en.wikipedia.org/wiki/Gregorian_calendar Talking about dates before this epoch makes little sense (any date before the Gregorian epoch will not resemble the same stellar / planet constellation as date after the Gregorian epoch).
  • pjscott 5y ago
    A precision of 100 ns is not bad, just inflexible; I didn't mean to imply otherwise. The epoch is weird, though. Here's a thought experiment: imagine that a hundred programmers are each asked to pick an epoch for a timestamp, and will be paid $1000 for each other programmer who chooses the same epoch, but they can't talk with each other to coordinate. Which would you pick? I would pick the Unix epoch, because I think others would do the same. Anything else is, in a certain important sense, weird.
    • ericb 5y ago
      This is a great example of a Schelling Point! I'd also argue that you're right, and that as a principle, good UI/UX and software architecture should default to following natural Schelling Points.
    • zamadatix 5y ago
      Yet that thought process wouldn't allow for the Unix epoch in the first place.
    • FactolSarin 5y ago
      That doesn't make the epoch weird, just different. The Unix Epoch is itself weird. I personally like it mostly for being a neat little historical artifact, but it's not interesting in any sense. What epoch would your hypothetical programmers settle on if they all had their minds wiped of any existing epochs. I bet you'd see a lot of Jan 1 1900, 2000, or year 1. Very few would pick 1970. Other fun non-Jan 1 ideas might be December 26, 1791 (Charles Babbage's birthday) or February 5, 1944, (the date Colossus came online)
      • bombcar 5y ago
        1970 makes sense if you’re picking an epoch and you are in the 70s - everything will happen “after” your start date but picking the actual current date doesn’t seem natural enough. It’s like picking 2020 as the beginning of an epoch now (of course we’d probably fall back to 2000 as that’s a big round number).
      • mjevans 5y ago
        It makes a great deal of sense when thinking about the use case: recording a monotinic time in a computing environment with limited resources and extremely unlikely to ever see files from before midnight of new years eve 1970. With a great deal of existing routines that work with those values and a good number of existing files and storage applications based on the simple version, it makes even mores sense to extend that in an unsigned way with a larger bitfield for any timestamp. Though as recently came up, leap seconds and synchronization could use a few bits to describe which timestamp is in use.
      • fsagx 5y ago
        Other fun non-Jan 1 ideas 1997-08-29T06:14:00Z
    • zvrba 5y ago
      > Here's a thought experiment [...] I would pick the Unix epoch, because I think others would do the same. Ah yes, nobody will ever need to represent a date/time before 1970-01-01. As for your thought experiment: recently I had to pick a "NULL/no/unknown date" value to put into a non-nullable database column and I picked 1900-01-01. Unix epoch crossed my mind only briefly and I discarded it immediately because it's too arbitrary and, more importantly, too near valid dates that the user might use. (Use-case: materials from historical archives being ingested.) So my opinion is that the RFC authors should be commended for having the foresight of choosing an epoch that's widely more applicable and far less arbitrary (the 1st day of the calendar system that most of the world is using today) than the Unix epoch.
      • michaelt 5y ago
        > Ah yes, nobody will ever need to represent a date/time before 1970-01-01. If only we had a way to represent numbers less than zero :)
        • account42 5y ago
          Will UUIDs with your favourite encoding for negative numbers put 1969-01-01 before or after 1970-01-01 with a lexicographical sort of the UUID bytes?
          • deleted 5y ago
            [deleted]
      • scottlamb 5y ago
        > Ah yes, nobody will ever need to represent a date/time before 1970-01-01. More like: the few people interested in doing this can use UUIDv8 (unspecified time format). There are many, many reasons to store times before 1970 in computer systems, but I'm not sure any apply to these UUID formats. tl;dr of the "Background" section of the RFC: they're designing it so that two UUIDs with fresh timestamps will have values near each other in the database keyspace, which in many cases improves efficiency. If your timestamp isn't freshly generated, I don't know why you'd embed it in a UUID with these formats. It's arguably not a good practice to extract the timestamp from the UUID at all. Instead, I might just treat them once generated as opaque approximately-sorted bytes. More clear to have a separate fields for timestamps with particular importance. Though I might not feel too religious about that if tight on storage space.
  • jefftk 5y ago
    > Talking about dates before this epoch makes little sense (any date before the Gregorian epoch will not resemble the same stellar / planet constellation as date after the Gregorian epoch). That is not the only sense in which we care about dates. For example, we might want to talk about which of two events came first, and by how much. Historians have lots of uses for dates before the introduction of the Gregorian calendar.
    • SBArbeit 5y ago
      Yes, but we won't need 100ns precision for those historical dates.
    • contravariant 5y ago
      Surely they'd be using some kind of timestamp standard not a UUID?
    • zvrba 5y ago
      Historically, calendars came to be from observing the movement of planets and stars. Now: > we might want to talk about which of two events came first, and by how much Neither of which makes sense without having a common reference point (start of Gregorian calendar being one such possible reference point). Trivial example: there is exactly one day between 1582-10-04 (Julian c.) and 1582-10-15 (Gregorian c.), i.e., different reference points. > Historians have lots of uses for dates before the introduction of the Gregorian calendar. Yes, and I bet they're hyper-aware about the calendar system(s) they're using. The rest of our mortals can just use Gregorian calendar :)
  • ygra 5y ago
    Windows' FILETIME uses a different epoch, though. It counts since 1601 (the then-most-recent 400-year leap-year cycle when Windows NT was designed).
  • MrManatee 5y ago
    I wouldn't say it makes "little sense". Just like we can talk about the year 776 BC even though no one at the time called it that, we can extend the Gregorian calendar backwards to dates when it wasn't used anywhere. The Wikipedia article on the proleptic Gregorian calendar lists some use cases. [1] And in any case, 15 October 1582 isn't some hard cutoff point where we can stop worrying about calendar conversions. Only four countries adopted the Gregorian calendar on that day, and even in Europe there are several countries that only switched in the 20th century. If a piece of software needs to support historical dates that go anywhere near 1582, it needs to be aware of the existence of different calendars. [1] https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar
• hn_throwaway_99 5y ago
  To clarify, are those "plus some random bits" parts intended to be randomly generated for each individual UUID that is created, or randomly generated once per machine or startup? I ask because a common newbie bug is to use a UUID as a secure token, but currently only v4 UUIDs with a cryptographically secure PRNG can be used this way. Separately, even if not used as a token, using UUIDs with randomness for object IDs can help mitigate IDOR vulnerabilities if there are other bugs in code that aren't adequately checking object permissions.
  • pjscott 5y ago
    They're to be generated for each individual UUID. (However, this RFC recommends using the entirely random UUID4 for anything that's meant to be used in a security-related context, presumably with a CSPRNG.)
    • hn_throwaway_99 5y ago
      Thanks. To be honest then, that last bit, "this RFC recommends using the entirely random UUID4 for anything that's meant to be used in a security-related context, presumably with a CSPRNG." makes me think this RFC could cause some problems. v6 UUIDs only have 48 bits of randomness, which means that some newbies will think that's "good enough" for security, when in reality it's not. I still like these new UUID types because I would use them as DB primary keys now (benefit of being time sorted but also globally unique and offers some protection against IDOR bugs), but important to know where not to use them.
      • pjscott 5y ago
        Yeah, I'm a bit torn on this security-wise. On the one hand, their only real security-relevant ambition here is to avoid leaking MAC address info, a classic UUID foot-gun, and they do achieve this. Probably a much better set of defaults! On the other hand, yeah, the mere presence of some random bits could lull people into a false sense of safety, especially as the RFC doesn't say anything about where those bits should come from except that it should have enough entropy to make collisions minimal. On the third hand, anybody who thinks that 48 random bits of unspecified provenance are enough for a secure token was probably always going to mess up somehow, so I'm not sure how much difference this makes on the margin.
• paulddraper 5y ago
  8 kinds of UUIDs, because we already had 4 too many.
  • pjscott 5y ago
    Which of the 5 existing kinds of UUID do you consider the One True UUID? No matter which you pick, I guarantee that there's something badly wrong with it for at least one common use-case that can be improved by switching to either v4 (IMHO the only one of the existing types worth using) or to one of the new proposed UUID types.
    • paulddraper 5y ago
      UUID v4 Are you concerned about the 0.0000001% chance of collision after generating a 100 trillion UUIDs? Or are you trying to include metadata in your identifier? (Not the worst thing, but it's also not super useful info.)
      • pjscott 5y ago
        I'm not worried about collisions and I agree that being able to put metadata in the UUID is a big meh of a feature. The problem with v4 is what happens when people try using them as database keys: the random sort order can really hurt performance. You might argue that the fix for this is to simply not use UUIDs as database keys... but so many people are already doing this, and will continue to do it, that they should probably be given better standard options.
        • mdtusz 5y ago
          This is a fairly significant issue for mysql, but does the same issue exist when using postgres with a UUID pk type? At my last job, this was managed by using two ID's on each row - a serial one that was basically only used for database optimization purposes, and the "real" UUIDv4 ID. It felt gross then, and it feels gross now, but it seemed to do the trick for our needs.
• phkahler 5y ago
  >> but the downside is that there's no standard way to parse the time from one of these IMHO that should not be a concern. The goal of UUID is to create a Unique Identifier, not to record the time something was created. Maybe we should all have quantum random number generators, but with that I don't think 128 bits is enough for a UUID. Might be enough for specific applications though. First rule of database design: Your unique IDs should not have a real-world meaning.
  • mulmen 5y ago
    > First rule of database design: Your unique IDs should not have a real-world meaning. Well, this is an opinion. I would definitely push back on making it a rule. Especially the first one. Natural keys exist, make perfectly good unique identifiers, and have inherent meaning. When using synthetic keys it is difficult (read: requires making trade-offs) to guarantee they were created in order and/or that they increase monotonically. But if you make those trade-offs (or just align expectations) you can still associate real world meaning to them. These new UUIDs standardize more of those trade-offs.
    • tialaramex 5y ago
      > Natural keys exist, make perfectly good unique identifiers, and have inherent meaning. Most of the "natural" things you think are going to be good Primary Keys aren't. You quickly get into one of those "Falsehoods Programmers Believe About X" lists. I remember some years ago running into the Experian team who were designing a system to uniquely identify people and they'd got it all figured out for the US market. See, Americans have Social Security Numbers, so you can just use those to key off. Alas, as hopefully anybody here who actually deals with Social Security Numbers knows, they aren't unique. Perhaps you could argue they should be unique, but that's not useful in practice, because in practice they aren't. They seemed really disappointed about that. I doubt they fixed it though. It's far more likely that the "definitely unique" Natural key for your table isn't actually unique than that there will be an insurmountable problem caused by using artificial row IDs, UUIDs or something like that.
      • deleted 5y ago
• hinkley 5y ago
  > UUID6: a timestamp with a weird epoch and 100 ns precision like in UUID1, but in a big-endian order that sorts naturally by time So even the IETF hasn’t read Things Every Developer Should Know About Time.