UUIDv7 ne garantit ni monotonie ni précision du timestamp

Contexte et promesses initiales

Le standard RFC 9562 décrit UUIDv7 comme un identifiant contenant un horodatage, une partie aléatoire et un compteur. Les articles de vulgarisation mettent en avant trois bénéfices : ordre croissant, indication de création et impossibilité de deviner l’ID. En pratique, la spécification ne contraint pas l’implémentation à respecter ces propriétés ; elle autorise même la modification du champ timestamp.

Problèmes de précision du timestamp

Le champ temps d’un UUIDv7 n’est pas obligatoirement égal à l’horloge système. Le texte de la RFC indique que les implémentations MAY alter the timestamp (§6.1) et peuvent même l’avancer (§6.2). Aucun seuil d’écart n’est imposé, ce qui rend possible un décalage arbitraire entre le moment réel de génération et la valeur encodée.

import uuid
from datetime import datetime

t = uuid.uuid7().time
now = datetime.now()
delta = (datetime.fromtimestamp(t/1000) - now).total_seconds()
print("Initial delta: ", delta)
input("Set clock back one hour")
while True:
    for _ in range(100000):
        uuid.uuid7()
    t = uuid.uuid7().time
    now = datetime.now()
    delta = (datetime.fromtimestamp(t/1000) - now).total_seconds()
    print("New delta: ", delta)

Lorsque l’horloge système recule d’une heure, le script montre que le delta passe de ~‑0,001 s à plus de 3 600 s et continue de croître tant que le générateur produit plus d’un ID par milliseconde.

Comportement monotone et dépassements de compteur

UUIDv7 réserve au moins 12 bits pour le compteur, soit 4 096 valeurs par milliseconde. Au‑delà, le compteur déborde et la spécification autorise l’incrément du timestamp. Un taux de création supérieur à ce seuil entraîne alors un « timestamp ahead », même si l’horloge réelle n’avance pas. L’exemple Python montre que, sous charge élevée, le timestamp peut s’éloigner indéfiniment du temps système.

Sur un même nœud, les implémentations qui n’utilisent qu’un horodatage milliseconde sans compteur génèrent facilement des UUID hors ordre dans une boucle rapide, prouvant que la monotonie stricte n’est pas assurée.

Conséquences pratiques et limites

Le principal avantage réel de UUIDv7 reste l’unicité. La fuite du timestamp expose la date de création, ce qui peut être sensible dans des URL publiques ou des logs. Bien que l’impact soit souvent mineur, il existe des scénarios où la divulgation de métadonnées est inacceptable.

En résumé, les implémentations conformes à la RFC peuvent produire des UUID dont le timestamp est imprécis, qui ne sont pas strictement monotones et qui peuvent accélérer dans le futur sous forte charge. Les développeurs doivent donc ne pas compter sur l’ordre temporel ou la confidentialité du timestamp et envisager des solutions alternatives lorsqu’une garantie stricte est requise.