create-prisma-php-app 1.0.0

package/vendor/ramsey/uuid/docs/rfc4122/version2.rst

@@ -0,0 +1,273 @@
+.. _rfc4122.version2:
+
+=======================
+Version 2: DCE Security
+=======================
+
+.. tip::
+
+    DCE Security UUIDs are so-called because they were defined as part of the
+    "Authentication and Security Services" for the `Distributed Computing
+    Environment`_ (DCE) in the early 1990s.
+
+    Version 2 UUIDs are not widely used. See :ref:`rfc4122.version2.problems`
+    before deciding whether to use them.
+
+Like a :ref:`version 1 UUID <rfc4122.version1>`, a version 2 UUID uses the
+current time, along with the MAC address (or *node*) for a network interface on
+the local machine. Additionally, a version 2 UUID replaces the low part of the
+time field with a local identifier such as the user ID or group ID of the local
+account that created the UUID. This serves three purposes:
+
+1. You can know *when* the identifier was created (see
+   :ref:`rfc4122.version2.timestamp-problems`).
+2. You can know *where* the identifier was created.
+3. You can know *who* created the identifier.
+
+In a distributed system, these three pieces of information can be valuable. Not
+only is there no need for a central authority to generate identifiers, but you
+can determine what nodes in your infrastructure created the UUIDs, at what time
+they were created, and the account on the machine that created them.
+
+By default, ramsey/uuid will attempt to look up a MAC address for the machine it
+is running on, using this value as the node. If it cannot find a MAC address, it
+will generate a random node.
+
+.. code-block:: php
+    :caption: Use a domain to generate a version 2, DCE Security UUID
+    :name: rfc4122.version2.example
+
+    use Ramsey\Uuid\Uuid;
+
+    $uuid = Uuid::uuid2(Uuid::DCE_DOMAIN_PERSON);
+
+    printf(
+        "UUID: %s\nVersion: %d\nDate: %s\nNode: %s\nDomain: %s\nID: %s\n",
+        $uuid->toString(),
+        $uuid->getFields()->getVersion()?->value,
+        $uuid->getDateTime()->format('r'),
+        $uuid->getFields()->getNode()->toString(),
+        $uuid->getLocalDomainName(),
+        $uuid->getLocalIdentifier()->toString()
+    );
+
+This will generate a version 2 UUID and print out its string representation, the
+time the UUID was created, and the node used to create it, as well as the name
+of the local domain specified and the local domain identifier (in this case, a
+`POSIX`_ UID, automatically obtained from the local machine).
+
+It will look something like this:
+
+.. code-block:: text
+
+    UUID: 000001f5-5e9a-21ea-9e00-0242ac130003
+    Version: 2
+    Date: Thu, 05 Mar 2020 04:30:10 +0000
+    Node: 0242ac130003
+    Domain: person
+    ID: 501
+
+Just as with version 1 UUIDs, you may provide custom values for version 2 UUIDs,
+including local identifier, node, and clock sequence.
+
+.. code-block:: php
+    :caption: Provide custom identifier, node, and clock sequence to create a
+              version 2, DCE Security UUID
+    :name: rfc4122.version2.custom-example
+
+    use Ramsey\Uuid\Provider\Node\StaticNodeProvider;
+    use Ramsey\Uuid\Type\Hexadecimal;
+    use Ramsey\Uuid\Type\Integer;
+    use Ramsey\Uuid\Uuid;
+
+    $localId = new Integer(1001);
+    $nodeProvider = new StaticNodeProvider(new Hexadecimal('121212121212'));
+    $clockSequence = 63;
+
+    $uuid = Uuid::uuid2(
+        Uuid::DCE_DOMAIN_ORG,
+        $localId,
+        $nodeProvider->getNode(),
+        $clockSequence
+    );
+
+.. tip::
+
+    Version 2 UUIDs generated in ramsey/uuid are instances of UuidV2. Check out
+    the :php:class:`Ramsey\\Uuid\\Rfc4122\\UuidV2` API documentation to learn
+    more about what you can do with a UuidV2 instance.
+
+
+.. _rfc4122.version2.domains:
+
+Domains
+#######
+
+The *domain* value tells what the local identifier represents.
+
+If using the *person* or *group* domains, ramsey/uuid will attempt to look up
+these values from the local machine. On `POSIX`_ systems, it will use ``id -u``
+and ``id -g``, respectively. On Windows, it will use ``whoami`` and ``wmic``.
+
+The *org* domain is site-defined. Its intent is to identify the organization
+that generated the UUID, but since this can have different meanings for
+different companies and projects, you get to define its value.
+
+.. list-table:: DCE Security Domains
+    :widths: 30 70
+    :align: center
+    :header-rows: 1
+    :name: rfc4122.version2.table-domains
+
+    * - Constant
+      - Description
+    * - :php:const:`Uuid::DCE_DOMAIN_PERSON <Ramsey\\Uuid\\Uuid::DCE_DOMAIN_PERSON>`
+      - The local identifier refers to a *person* (e.g., UID).
+    * - :php:const:`Uuid::DCE_DOMAIN_GROUP <Ramsey\\Uuid\\Uuid::DCE_DOMAIN_GROUP>`
+      - The local identifier refers to a *group* (e.g., GID).
+    * - :php:const:`Uuid::DCE_DOMAIN_ORG <Ramsey\\Uuid\\Uuid::DCE_DOMAIN_ORG>`
+      - The local identifier refers to an *organization* (this is site-defined).
+
+.. note::
+
+    According to section 5.2.1.1 of `DCE 1.1: Authentication and Security Services
+    <https://publications.opengroup.org/c311>`_, the domain "can potentially hold
+    values outside the range [0, 2\ :sup:`8` -- 1]; however, the only values
+    currently registered are in the range [0, 2]."
+
+    As a result, ramsey/uuid supports only the *person*, *group*, and *org*
+    domains.
+
+
+.. _rfc4122.version2.nodes:
+
+Custom and Random Nodes
+#######################
+
+In the :ref:`example above <rfc4122.version2.custom-example>`, we provided a
+custom node when generating a version 2 UUID. You may also generate random
+node values.
+
+To learn more, see the :ref:`rfc4122.version1.custom` and
+:ref:`rfc4122.version1.random` sections under :ref:`rfc4122.version1`.
+
+
+.. _rfc4122.version2.clock:
+
+Clock Sequence
+##############
+
+In a version 2 UUID, the clock sequence serves the same purpose as in a version
+1 UUID. See :ref:`rfc4122.version1.clock` to learn more.
+
+.. warning::
+
+    The clock sequence in a version 2 UUID is a 6-bit number. It supports values
+    from 0 to 63. This is different from the 14-bit number used by version 1
+    UUIDs.
+
+    See :ref:`rfc4122.version2.uniqueness-problems` to understand how this
+    affects version 2 UUIDs.
+
+
+.. _rfc4122.version2.problems:
+
+Problems With Version 2 UUIDs
+#############################
+
+Version 2 UUIDs can be useful for the data they contain. However, there are
+trade-offs in choosing to use them.
+
+
+.. _rfc4122.version2.privacy-problems:
+
+Privacy
+-------
+
+Unless using a randomly-generated node, version 2 UUIDs use the MAC address for
+a local hardware interface as the node value. In addition, they use a local
+identifier --- usually an account or group ID. Some may consider the use of
+these identifying features a breach of privacy. The use of a timestamp further
+complicates the issue, since these UUIDs could be used to identify a user
+account on a specific machine at a specific time.
+
+If you don't need an identifier with a local identifier and timestamp value
+embedded in it, see :ref:`rfc4122.version4` to learn about random UUIDs.
+
+
+.. _rfc4122.version2.uniqueness-problems:
+
+Limited Uniqueness
+------------------
+
+With the inclusion of the local identifier and domain comes a serious limitation
+in the number of unique UUIDs that may be created. This is because:
+
+1. The local identifier replaces the lower 32 bits of the timestamp.
+2. The domain replaces the lower 8 bits of the clock sequence.
+
+As a result, the timestamp advances --- the clock *ticks* --- only once every
+429.49 seconds (about 7 minutes). This means the clock sequence is important to
+ensure uniqueness, but since the clock sequence is only 6 bits, compared to 14
+bits for version 1 UUIDs, **only 64 unique UUIDs per combination of node,
+domain, and identifier may be generated per 7-minute tick of the clock**.
+
+You can overcome this lack of uniqueness by using a
+:ref:`random node <rfc4122.version2.nodes>`, which provides 47 bits of
+randomness to the UUID --- after setting the unicast/multicast bit (see
+discussion on :ref:`rfc4122.version1.custom`) --- increasing the number of UUIDs
+per 7-minute clock tick to 2\ :sup:`53` (or 9,007,199,254,740,992), at the
+expense of remaining locally unique.
+
+.. note::
+
+    This lack of uniqueness did not present a problem for DCE, since:
+
+        [T]he security architecture of DCE depends upon the uniqueness of
+        security-version UUIDs *only within the context of a cell*; that is,
+        only within the context of the local [Registration Service's]
+        (persistent) datastore, and that degree of uniqueness can be guaranteed
+        by the RS itself (namely, the RS maintains state in its datastore, in
+        the sense that it can always check that every UUID it maintains is
+        different from all other UUIDs it maintains). In other words, while
+        security-version UUIDs are (like all UUIDs) specified to be "globally
+        unique in space and time", security is not compromised if they are
+        merely "locally unique per cell".
+
+        -- `DCE 1.1: Authentication and Security Services, section 5.2.1.1
+        <https://publications.opengroup.org/c311>`_
+
+
+.. _rfc4122.version2.timestamp-problems:
+
+Lossy Timestamps
+----------------
+
+Version 2 UUIDs are generated in the same way as version 1 UUIDs, but the low
+part of the timestamp (the ``time_low`` field) is replaced by a 32-bit integer
+that represents a local identifier. Because of this, not only do version 2 UUIDs
+have :ref:`limited uniqueness <rfc4122.version2.uniqueness-problems>`, but they
+also lack time precision.
+
+When reconstructing the timestamp to return a `DateTimeInterface`_ instance from
+:php:meth:`UuidV2::getDateTime() <Ramsey\\Uuid\\Rfc4122\\UuidV2::getDateTime>`,
+we replace the 32 lower bits of the timestamp with zeros, since the local
+identifier should not be part of the timestamp. This results in a loss of
+precision, causing the timestamp to be off by a range of 0 to 429.4967295
+seconds (or 7 minutes, 9 seconds, and 496,730 microseconds).
+
+When using version 2 UUIDs, treat the timestamp as an approximation. At worst,
+it could be off by about 7 minutes.
+
+.. hint::
+
+    If the value 429.4967295 looks familiar, it's because it directly
+    corresponds to 2\ :sup:`32` -- 1, or ``0xffffffff``. The local identifier is
+    32-bits, and we have set each of these bits to 0, so the maximum range of
+    timestamp drift is ``0x00000000`` to ``0xffffffff`` (counted in
+    100-nanosecond intervals).
+
+
+.. _Distributed Computing Environment: https://en.wikipedia.org/wiki/Distributed_Computing_Environment
+.. _POSIX: https://en.wikipedia.org/wiki/POSIX
+.. _DateTimeInterface: https://www.php.net/datetimeinterface

package/vendor/ramsey/uuid/docs/rfc4122/version3.rst

@@ -0,0 +1,68 @@
+.. _rfc4122.version3:
+
+===========================
+Version 3: Name-based (MD5)
+===========================
+
+.. attention::
+
+    `RFC 4122`_ states, "If backward compatibility is not an issue, SHA-1 is
+    preferred." As a result, the use of :ref:`version 5 UUIDs
+    <rfc4122.version5>` is preferred over version 3 UUIDs, unless you have a
+    specific use-case for version 3 UUIDs.
+
+.. note::
+
+    To learn about name-based UUIDs, read the section :ref:`rfc4122.version5`.
+    Version 3 UUIDs behave exactly the same as :ref:`version 5 UUIDs
+    <rfc4122.version5>`. The only difference is the hashing algorithm used to
+    generate the UUID.
+
+    Version 3 UUIDs use `MD5`_ as the hashing algorithm for combining
+    the namespace and the name.
+
+Due to the use of a different hashing algorithm, version 3 UUIDs generated with
+any given namespace and name will differ from version 5 UUIDs generated using
+the same namespace and name.
+
+As an example, let's take a look at generating a version 3 UUID using the same
+namespace and name used in ":ref:`rfc4122.version5.url-example`."
+
+.. code-block:: php
+    :caption: Generate a version 3, name-based UUID for a URL
+    :name: rfc4122.version3.url-example
+
+    use Ramsey\Uuid\Uuid;
+
+    $uuid = Uuid::uuid3(Uuid::NAMESPACE_URL, 'https://www.php.net');
+
+Even though the namespace and name are the same, the version 3 UUID generated
+will always be ``3f703955-aaba-3e70-a3cb-baff6aa3b28f``.
+
+Likewise, we can use the custom namespace we created in
+":ref:`rfc4122.version5.create-namespace`" to generate a version 3 UUID, but the
+result will be different from the version 5 UUID with the same custom namespace
+and name.
+
+.. code-block:: php
+    :caption: Use a custom namespace to create version 3, name-based UUIDs
+    :name: rfc4122.version3.custom-example
+
+    use Ramsey\Uuid\Uuid;
+
+    const WIDGET_NAMESPACE = '4bdbe8ec-5cb5-11ea-bc55-0242ac130003';
+
+    $uuid = Uuid::uuid3(WIDGET_NAMESPACE, 'widget/1234567890');
+
+With this custom namespace, the version 3 UUID for the name "widget/1234567890"
+will always be ``53564aa3-4154-3ca5-ac90-dba59dc7d3cb``.
+
+.. tip::
+
+    Version 3 UUIDs generated in ramsey/uuid are instances of UuidV3. Check out
+    the :php:class:`Ramsey\\Uuid\\Rfc4122\\UuidV3` API documentation to learn
+    more about what you can do with a UuidV3 instance.
+
+
+.. _RFC 4122: https://tools.ietf.org/html/rfc4122
+.. _MD5: https://en.wikipedia.org/wiki/MD5

package/vendor/ramsey/uuid/docs/rfc4122/version4.rst

@@ -0,0 +1,39 @@
+.. _rfc4122.version4:
+
+=================
+Version 4: Random
+=================
+
+Version 4 UUIDs are perhaps the most popular form of UUID. They are
+randomly-generated and do not contain any information about the time they are
+created or the machine that generated them. If you don't care about this
+information, then a version 4 UUID might be perfect for your needs.
+
+.. code-block:: php
+    :caption: Generate a version 4, random UUID
+    :name: rfc4122.version4.example
+
+    use Ramsey\Uuid\Uuid;
+
+    $uuid = Uuid::uuid4();
+
+    printf(
+        "UUID: %s\nVersion: %d\n",
+        $uuid->toString(),
+        $uuid->getFields()->getVersion()?->value
+    );
+
+This will generate a version 4 UUID and print out its string representation.
+It will look something like this:
+
+.. code-block:: text
+
+    UUID: 1ee9aa1b-6510-4105-92b9-7171bb2f3089
+    Version: 4
+
+
+.. tip::
+
+    Version 4 UUIDs generated in ramsey/uuid are instances of UuidV4. Check out
+    the :php:class:`Ramsey\\Uuid\\Rfc4122\\UuidV4` API documentation to learn
+    more about what you can do with a UuidV4 instance.

package/vendor/ramsey/uuid/docs/rfc4122/version5.rst

@@ -0,0 +1,108 @@
+.. _rfc4122.version5:
+
+=============================
+Version 5: Name-based (SHA-1)
+=============================
+
+.. danger::
+
+    Since :ref:`version 3 <rfc4122.version3>` and version 5 UUIDs essentially
+    use a *salt* (the namespace) to hash data, it may be tempting to use them to
+    hash passwords. **DO NOT do this under any circumstances!** You should not
+    store any sensitive information in a version 3 or version 5 UUID, since `MD5
+    and SHA-1 are insecure and have known attacks demonstrated against them
+    <https://en.wikipedia.org/wiki/Hash_function_security_summary>`_. *Use these
+    types of UUIDs as identifiers only.*
+
+The first thing that comes to mind with most people think of a UUID is a
+*random* identifier, but name-based UUIDs aren't random at all. In fact, they're
+deterministic. For any given identical namespace and name, you will always
+generate the same UUID.
+
+Name-based UUIDs are useful when you need an identifier that's based on
+something's *name* --- think *identity* --- and will always be the same no
+matter where or when it is created.
+
+For example, let's say I want to create an identifier for a URL. I could use
+a :ref:`version 1 <rfc4122.version1>` or :ref:`version 4 <rfc4122.version4>`
+UUID to create an identifier for the URL, but what if I'm working with a
+distributed system, and I want to ensure that every client in this system can
+always generate the same identifier for any given URL?
+
+This is where a name-based UUID comes in handy.
+
+Name-based UUIDs combine a namespace with a name. This way, the UUIDs are unique
+to the namespace they're created in. `RFC 4122`_ defines some
+:ref:`predefined namespaces <reference.name-based-namespaces>`, one of which is
+for URLs.
+
+.. note::
+
+    Version 5 UUIDs use `SHA-1`_ as the hashing algorithm for combining the
+    namespace and the name.
+
+.. code-block:: php
+    :caption: Generate a version 5, name-based UUID for a URL
+    :name: rfc4122.version5.url-example
+
+    use Ramsey\Uuid\Uuid;
+
+    $uuid = Uuid::uuid5(Uuid::NAMESPACE_URL, 'https://www.php.net');
+
+The UUID generated will always be the same, as long as the namespace and name
+are the same. The version 5 UUID for "https://www.php.net" in the URL namespace
+will always be ``a8f6ae40-d8a7-58f0-be05-a22f94eca9ec``. See for yourself. Run
+the code above, and you'll see it always generates the same UUID.
+
+.. tip::
+
+    Version 5 UUIDs generated in ramsey/uuid are instances of UuidV5. Check out
+    the :php:class:`Ramsey\\Uuid\\Rfc4122\\UuidV5` API documentation to learn
+    more about what you can do with a UuidV5 instance.
+
+
+.. _rfc4122.version5.custom-namespaces:
+
+Custom Namespaces
+#################
+
+If you're working with name-based UUIDs for names that don't fit into any of
+the :ref:`predefined namespaces <reference.name-based-namespaces>`, or you don't
+want to use any of the predefined namespaces, you can create your own namespace.
+
+The best way to do this is to generate a :ref:`version 1 <rfc4122.version1>` or
+:ref:`version 4 <rfc4122.version4>` UUID and save this UUID as your namespace.
+
+.. code-block:: php
+    :caption: Generate a custom namespace UUID
+    :name: rfc4122.version5.create-namespace
+
+    use Ramsey\Uuid\Uuid;
+
+    $uuid = Uuid::uuid1();
+
+    printf("My namespace UUID is %s\n", $uuid->toString());
+
+This will generate a version 1, Gregorian time UUID, which we'll store to a
+constant so we can reuse it as our own custom namespace.
+
+.. code-block:: php
+    :caption: Use a custom namespace to create version 5, name-based UUIDs
+    :name: rfc4122.version5.custom-example
+
+    use Ramsey\Uuid\Uuid;
+
+    const WIDGET_NAMESPACE = '4bdbe8ec-5cb5-11ea-bc55-0242ac130003';
+
+    $uuid = Uuid::uuid5(WIDGET_NAMESPACE, 'widget/1234567890');
+
+With this custom namespace, the version 5 UUID for the name "widget/1234567890"
+will always be ``a35477ae-bfb1-5f2e-b5a4-4711594d855f``.
+
+We can publish this namespace, allowing others to use it to generate identifiers
+for widgets. When two or more systems try to reference the same widget, they'll
+end up generating the same identifier for it, which is exactly what we want.
+
+
+.. _RFC 4122: https://tools.ietf.org/html/rfc4122
+.. _SHA-1: https://en.wikipedia.org/wiki/SHA-1

package/vendor/ramsey/uuid/docs/rfc4122/version6.rst

@@ -0,0 +1,213 @@
+.. _rfc4122.version6:
+
+=========================
+Version 6: Reordered Time
+=========================
+
+.. note::
+
+    Version 6, reordered time UUIDs are a new format of UUID, proposed in an
+    `Internet-Draft under review`_ at the IETF. While the draft is still going
+    through the IETF process, the version 6 format is not expected to change
+    in any way that breaks compatibility.
+
+.. attention::
+
+    If you need a time-based UUID, and you don't need the other features
+    included in version 6 UUIDs, we recommend using
+    :ref:`version 7 UUIDs <rfc4122.version7>`.
+
+Version 6 UUIDs solve `two problems that have long existed`_ with the use of
+:ref:`version 1 <rfc4122.version1>` UUIDs:
+
+1. Scattered database records
+2. Inability to sort by an identifier in a meaningful way (i.e., insert order)
+
+To overcome these issues, we need the ability to generate UUIDs that are
+*monotonically increasing* while still providing all the benefits of version
+1 UUIDs.
+
+Version 6 UUIDs do this by storing the time in standard byte order, instead of
+breaking it up and rearranging the time bytes, according to the `RFC 4122`_
+definition. All other fields remain the same, and the version maintains its
+position, according to RFC 4122.
+
+In all other ways, version 6 UUIDs function like version 1 UUIDs.
+
+.. tip::
+
+    Prior to version 4.0.0, ramsey/uuid provided a solution for this with the
+    :ref:`ordered-time codec <customize.ordered-time-codec>`. Use of the
+    ordered-time codec is still valid and acceptable. However, you may replace
+    UUIDs generated using the ordered-time codec with version 6 UUIDs. Keep
+    reading to find out how.
+
+.. code-block:: php
+    :caption: Generate a version 6, reordered time UUID
+    :name: rfc4122.version6.example
+
+    use Ramsey\Uuid\Uuid;
+
+    $uuid = Uuid::uuid6();
+
+    printf(
+        "UUID: %s\nVersion: %d\nDate: %s\nNode: %s\n",
+        $uuid->toString(),
+        $uuid->getFields()->getVersion()?->value,
+        $uuid->getDateTime()->format('r'),
+        $uuid->getFields()->getNode()->toString()
+    );
+
+This will generate a version 6 UUID and print out its string representation, the
+time the UUID was created, and the node used to create the UUID.
+
+It will look something like this:
+
+.. code-block:: text
+
+    UUID: 1ea60f56-b67b-61fc-829a-0242ac130003
+    Version: 6
+    Date: Sun, 08 Mar 2020 04:29:37 +0000
+    Node: 0242ac130003
+
+You may provide custom values for version 6 UUIDs, including node and clock
+sequence.
+
+.. code-block:: php
+    :caption: Provide custom node and clock sequence to create a version 6,
+              reordered time UUID
+    :name: rfc4122.version6.custom-example
+
+    use Ramsey\Uuid\Provider\Node\StaticNodeProvider;
+    use Ramsey\Uuid\Type\Hexadecimal;
+    use Ramsey\Uuid\Uuid;
+
+    $nodeProvider = new StaticNodeProvider(new Hexadecimal('121212121212'));
+    $clockSequence = 16383;
+
+    $uuid = Uuid::uuid6($nodeProvider->getNode(), $clockSequence);
+
+.. tip::
+
+    Version 6 UUIDs generated in ramsey/uuid are instances of UuidV6. Check out
+    the :php:class:`Ramsey\\Uuid\\Rfc4122\\UuidV6` API documentation to
+    learn more about what you can do with a UuidV6 instance.
+
+
+.. _rfc4122.version6.nodes:
+
+Custom and Random Nodes
+#######################
+
+In the :ref:`example above <rfc4122.version6.custom-example>`, we provided a
+custom node when generating a version 6 UUID. You may also generate random
+node values.
+
+To learn more, see the :ref:`rfc4122.version1.custom` and
+:ref:`rfc4122.version1.random` sections under :ref:`rfc4122.version1`.
+
+
+.. _rfc4122.version6.clock:
+
+Clock Sequence
+##############
+
+In a version 6 UUID, the clock sequence serves the same purpose as in a version
+1 UUID. See :ref:`rfc4122.version1.clock` to learn more.
+
+
+.. _rfc4122.version6.version1-conversion:
+
+Version 1-to-6 Conversion
+#########################
+
+It is possible to convert back-and-forth between version 6 and version 1 UUIDs.
+
+.. code-block:: php
+    :caption: Convert a version 1 UUID to a version 6 UUID
+    :name: rfc4122.version6.convert-version1-example
+
+    use Ramsey\Uuid\Rfc4122\UuidV1;
+    use Ramsey\Uuid\Rfc4122\UuidV6;
+    use Ramsey\Uuid\Uuid;
+
+    $uuid1 = Uuid::fromString('3960c5d8-60f8-11ea-bc55-0242ac130003');
+
+    if ($uuid1 instanceof UuidV1) {
+        $uuid6 = UuidV6::fromUuidV1($uuid1);
+    }
+
+.. code-block:: php
+    :caption: Convert a version 6 UUID to a version 1 UUID
+    :name: rfc4122.version6.convert-version6-example
+
+    use Ramsey\Uuid\Rfc4122\UuidV6;
+    use Ramsey\Uuid\Uuid;
+
+    $uuid6 = Uuid::fromString('1ea60f83-960c-65d8-bc55-0242ac130003');
+
+    if ($uuid6 instanceof UuidV6) {
+        $uuid1 = $uuid6->toUuidV1();
+    }
+
+
+.. _rfc4122.version6.ordered-time-conversion:
+
+Ordered-time to Version 6 Conversion
+####################################
+
+You may convert UUIDs previously generated and stored using the
+:ref:`ordered-time codec <customize.ordered-time-codec>` into version 6 UUIDs.
+
+.. caution::
+
+    If you perform this conversion, the bytes and string representation of your
+    UUIDs will change. This will break any software that expects your
+    identifiers to be fixed.
+
+.. code-block:: php
+    :caption: Convert an ordered-time codec encoded UUID to a version 6 UUID
+    :name: rfc4122.version6.convert-ordered-time-example
+
+    use Ramsey\Uuid\Codec\OrderedTimeCodec;
+    use Ramsey\Uuid\Rfc4122\UuidV1;
+    use Ramsey\Uuid\Rfc4122\UuidV6;
+    use Ramsey\Uuid\UuidFactory;
+
+    // The bytes of a version 1 UUID previously stored in some datastore
+    // after encoding to bytes with the OrderedTimeCodec.
+    $bytes = hex2bin('11ea60faf17c8af6ad23acde48001122');
+
+    $factory = new UuidFactory();
+    $codec = new OrderedTimeCodec($factory->getUuidBuilder());
+
+    $factory->setCodec($codec);
+
+    $orderedTimeUuid = $factory->fromBytes($bytes);
+
+    if ($orderedTimeUuid instanceof UuidV1) {
+        $uuid6 = UuidV6::fromUuidV1($orderedTimeUuid);
+    }
+
+
+.. _rfc4122.version6.privacy:
+
+Privacy Concerns
+################
+
+Like :ref:`version 1 UUIDs <rfc4122.version1>`, version 6 UUIDs use a MAC
+address from a local hardware network interface. This means it is possible to
+uniquely identify the machine on which a version 6 UUID was created.
+
+If the value provided by the timestamp of a version 6 UUID is important to you,
+but you do not wish to expose the interface address of any of your local
+machines, see :ref:`rfc4122.version6.nodes`.
+
+If you do not need an identifier with a node value embedded in it, but you still
+need the benefit of a monotonically increasing unique identifier, see
+:ref:`rfc4122.version7`.
+
+
+.. _Internet-Draft under review: https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc4122bis-00#section-5.6
+.. _two problems that have long existed: https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/
+.. _RFC 4122: https://tools.ietf.org/html/rfc4122