FR
RU
EN
ES
ZH
DE
PT
AR
HI
Temps en millisecondes en Rust : ne tombez pas dans ces 5 pièges
\n\n« Comment obtenir l'heure actuelle en millisecondes ? » — cette question sur Stack Overflow a recueilli des milliers de vues. Quoi de plus simple, semble-t-il ? Mais Rust n'est ni Python ni JavaScript. Il est facile de confondre UNIX timestamp avec le temps monotone, d'oublier la dépendance à la plateforme ou de se heurter à des problèmes de performance.
Dans cet article, nous analyserons les principales erreurs que commettent les débutants (et les autres) lorsqu'ils travaillent avec le temps en Rust. Vous apprendrez à obtenir le temps en millisecondes correctement, de manière fiable et rapide. C'est parti !
\n\nErreur n°1 : Temps monotone au lieu du temps UNIX
\n\nLe piège le plus courant est d'utiliser std::time::Instant pour obtenir « l'heure actuelle ». Instant en Rust mesure le temps monotone — il est parfait pour mesurer des intervalles, mais totalement inutile si vous avez besoin d'un timestamp (par exemple, pour la journalisation ou l'envoi à un serveur).
// ❌ ERREUR : on ne peut pas obtenir un timestamp ainsi\nuse std::time::Instant;\n\nlet now = Instant::now();\n// Instant n'a pas de méthode duration_since(UNIX_EPOCH) !\n// Vous obtiendrez une erreur de compilation\nComment faire correctement ? Utilisez std::time::SystemTime. Ce type connaît l'heure système et peut compter à partir de UNIX_EPOCH (1er janvier 1970).
use std::time::{SystemTime, UNIX_EPOCH};\n\nlet now = SystemTime::now()\n .duration_since(UNIX_EPOCH)\n .expect("Le temps a reculé ?");\n \nlet millis = now.as_millis(); // u128\nprintln!("Heure actuelle en ms : {}", millis);\n💡 Conseil : duration_since retourne un Result, car théoriquement l'heure système peut être réglée avant 1970. Sur les systèmes modernes, cette exception peut être traitée en toute sécurité avec expect ou unwrap.
Erreur n°2 : Oublier la dépendance à la plateforme
\n\nApparemment, SystemTime::now() est une solution multiplateforme. Mais il y a un hic. Sur certaines plateformes (par exemple, les anciens noyaux Linux ou les systèmes embarqués), SystemTime peut se comporter de manière instable ou même ne pas supporter la précision à la milliseconde.
Deuxième écueil : le dépassement de capacité. Le type u128 dans as_millis() est peu susceptible de déborder (il suffit pour des milliards d'années), mais si vous devez stocker l'heure dans une base de données ou la transmettre sur un réseau — les millisecondes en u128 peuvent surprendre d'autres systèmes.
// ✅ Conversion sécurisée en u64 (suffit pour ~584 millions d'années)\nlet millis_u64: u64 = now.as_millis() as u64;\nComment l'éviter ? Vérifiez toujours la documentation de votre plateforme cible. Pour les systèmes embarqués, envisagez la crate embassy-time ou utilisez std::time avec précaution.
Erreur n°3 : Ignorer la crate chrono
\n\nLa bibliothèque standard de Rust offre des fonctionnalités de base. Mais si vous devez travailler avec des fuseaux horaires, le formatage ou l'analyse de dates — ne réinventez pas la roue. La crate chrono est la norme de facto pour travailler avec les dates et l'heure en Rust.
// Ajoutez dans Cargo.toml : chrono = "0.4"\nuse chrono::Utc;\n\nlet now = Utc::now();\nlet millis = now.timestamp_millis(); // i64\nprintln!("Chrono timestamp : {}", millis);\n⚠️ Important : timestamp_millis() retourne un i64, pas un u128. Cela est fait pour la compatibilité avec le temps UNIX (qui peut être négatif pour les dates antérieures à 1970). Dans la plupart des cas, i64 est ce dont vous avez besoin.
💡 Co
