PowerShell Get-Date : formater la date en string, timestamp, ISO 8601 et plus

PowerShell Get-Date renvoie par défaut un objet date et heure, pas une chaîne prête à enregistrer dans un fichier ou à envoyer à une API. Pour formater une date, choisissez d’abord le type de résultat attendu : une valeur lisible, une date en chaîne de caractères, un timestamp Unix ou un format ISO 8601. Cette distinction évite bien des surprises dans les scripts exécutés sur des machines configurées avec des langues ou des fuseaux différents.

Pour un nom de fichier, un journal applicatif ou un échange entre systèmes, une représentation déterministe est préférable au format d’affichage local. Pour calculer une durée ou comparer deux instants, gardez plutôt un objet DateTime jusqu’au moment où une conversion en texte devient nécessaire. Le formatage de date PowerShell repose notamment sur les modèles .NET avec -Format, tandis que -UFormat utilise des marqueurs précédés du signe %. Les deux options renvoient une chaîne, ce qui change ce qu’il est possible de faire ensuite avec le résultat.

En bref :

• Get-Date produit un objet date et heure, pratique pour les calculs.

• Get-Date -Format 'yyyy-MM-dd' crée une chaîne stable pour un fichier ou un export.

• Get-Date -Format o fournit une représentation .NET de type aller-retour, avec les informations de décalage disponibles.

• Un timestamp Unix compte les secondes depuis le 1er janvier 1970 en UTC ; il ne faut pas le confondre avec des millisecondes.

• La culture et le fuseau horaire peuvent modifier l’affichage ou l’interprétation d’une date sans format explicite.

PowerShell Get-Date : conserver un objet ou produire une chaîne

Sans paramètre de formatage, Get-Date renvoie un objet .NET de type DateTime. La console l’affiche sous une forme adaptée à la culture active de Windows ou de PowerShell, mais cet affichage n’est pas le type de la valeur. Cette différence compte dès qu’un script enchaîne un calcul, une comparaison et un export.

Pour inspecter le résultat, une commande comme Get-Date | Get-Member montre les propriétés et méthodes disponibles. Parmi elles, Year, Month, DayOfYear ou IsDaylightSavingTime() permettent d’extraire des informations sans transformer prématurément l’objet en texte.

La variante Get-Date -DisplayHint Date modifie surtout la manière dont la date est présentée dans la console. Elle ne remplace pas un modèle de formatage destiné à un fichier. Pour une valeur exploitable par la suite, conservez l’objet dans une variable : $dateExecution = Get-Date.

Cette variable peut ensuite servir à mesurer une opération avec New-TimeSpan, à ajouter des jours ou à comparer deux instants. Par exemple, $dateExecution.AddDays(7) renvoie une nouvelle date une semaine plus tard. Les calculs restent lisibles et ne dépendent pas de l’ordre jour-mois utilisé par la langue locale.

La situation change avec -Format. La commande Get-Date -Format 'yyyy-MM-dd' renvoie une chaîne, ici une date telle que 2026-04-17. C’est pratique pour un nom de répertoire ou un en-tête de rapport, mais cette chaîne ne possède plus directement les méthodes de DateTime.

La conversion peut aussi se faire après coup avec $dateExecution.ToString('yyyy-MM-dd'). Cette forme rend la séparation entre calcul et présentation très claire : l’objet reste disponible pour la logique du script, puis la conversion intervient au moment de produire un texte.

Un piège revient souvent dans les scripts de sauvegarde : utiliser la sortie affichée par défaut comme nom de fichier. Selon la culture, une date peut contenir des barres obliques, des noms de mois ou une organisation différente des composants. Ces caractères rendent parfois un chemin ambigu, voire invalide.

Dans une tâche planifiée exécutée sous un compte de service, la culture active peut aussi différer de celle de la session interactive de l’administrateur. Une commande testée à la main peut donc produire une chaîne différente en production. Pour les traitements automatisés, mieux vaut définir explicitement un modèle plutôt que compter sur l’affichage local.

Le bon réflexe : garder DateTime pour les opérations, convertir en chaîne au bord du système, au moment d’écrire un fichier, de construire un message ou d’appeler un programme externe. Cette séparation évite de traiter du texte comme s’il s’agissait encore d’une date.

Formater une date avec les modèles .NET et les formats personnalisés

Le paramètre -Format de Get-Date s’appuie sur les modèles de date et d’heure .NET. Il renvoie directement une chaîne : Get-Date -Format 'dddd dd MMMM yyyy HH:mm:ss' produit, selon la culture active, le jour écrit en toutes lettres, la date et l’heure sur 24 heures.

Les majuscules et les minuscules ont un sens. Dans un modèle personnalisé, MM désigne le mois, tandis que mm correspond aux minutes. De même, HH donne l’heure sur 24 heures et hh l’heure sur 12 heures. Une seule lettre peut suffire dans certains modèles, mais les deux caractères rendent souvent le résultat plus lisible.

Modèle	Signification	Exemple d’usage
yyyyMMdd	Année, mois et jour, sans séparateur	Nom de fichier triable
yyyy-MM-dd	Date avec année sur quatre chiffres	Échange ou journal
HH:mm:ss	Heure sur 24 heures, secondes comprises	Trace d’exécution
yyyy-MM-ddTHH:mm:ss	Date et heure, séparées par T	Chaîne proche de l’ISO 8601
o	Modèle standard .NET aller-retour	Conserver la précision et le décalage

Pour un nom de dossier, un format compact comme yyyyMMdd-HHmmss est souvent plus pratique que l’affichage par défaut. Les deux composants se trient dans l’ordre chronologique lorsqu’ils sont placés dans cet ordre. Les deux-points, eux, sont à éviter dans les noms de fichiers Windows.

Le modèle ISO 8601 est utile pour échanger des dates entre outils, mais il faut choisir si l’heure doit être locale ou UTC. Une chaîne comme 2026-04-17T09:30:00 sans décalage ne permet pas de savoir quel fuseau elle représente. La présence de Z indique UTC ; un suffixe tel que +02:00 exprime un décalage explicite.

Pour conserver les informations de DateTime sous une forme standard .NET, Get-Date -Format o produit une chaîne de format aller-retour. Dans un script, le format personnalisé yyyy-MM-dd'T'HH:mm:ssK peut aussi convenir, si la valeur contient un type et un fuseau interprétables. Le marqueur K affiche les informations de fuseau disponibles ; il ne transforme pas, à lui seul, une heure locale en UTC.

PowerShell propose également des formats pratiques comme FileDate, FileDateUniversal, FileDateTime et FileDateTimeUniversal. Ils évitent de reconstruire à la main des modèles courants pour les noms de fichiers. Avant de les déployer sur un parc ancien, vérifiez toutefois la version de PowerShell utilisée par les machines.

Le formatage personnalisé ne doit pas remplacer les calculs. Si un rapport doit afficher une durée entre deux opérations, calculez cette durée à partir des objets DateTime, puis formatez seulement le résultat destiné au lecteur. Le texte est une sortie ; ce n’est pas une bonne structure de travail pour une date.

Créer un timestamp Unix et convertir une date en PowerShell

Un timestamp Unix représente un instant par un nombre de secondes écoulées depuis le 1er janvier 1970 à minuit UTC. Ce repère est courant dans les API, les outils Linux et les journaux techniques. Il est compact, mais difficile à lire sans conversion et facile à confondre avec une valeur en millisecondes.

Dans PowerShell 7.1 et les versions ultérieures, Get-Date -UnixTimeSeconds permet de convertir directement un timestamp en date. Par exemple, Get-Date -UnixTimeSeconds 0 représente le début de l’époque Unix. Pour obtenir un timestamp depuis une date, on peut utiliser un objet DateTimeOffset : DateTimeOffset.ToUnixTimeSeconds().

La conversion vers DateTimeOffset rend le décalage explicite avant le calcul. C’est un choix préférable à une manipulation manuelle de secondes autour d’une date locale, en particulier lorsque le passage à l’heure d’été intervient dans l’intervalle considéré.

Une API peut attendre des millisecondes plutôt que des secondes. Dans ce cas, la valeur est généralement beaucoup plus grande, et envoyer des secondes à la place peut déplacer l’instant obtenu vers une date très éloignée ou provoquer une erreur de validation. Le nom du champ de l’API ou sa documentation doit trancher, pas la taille estimée à l’œil.

Pour les versions antérieures à PowerShell 7.1, une conversion reste possible avec les méthodes .NET. La propriété UtcNow de DateTimeOffset représente l’instant courant en UTC, et ToUnixTimeSeconds() en fournit le nombre de secondes. Cette approche est utile pour des scripts compatibles avec Windows PowerShell 5.1, à condition que les types nécessaires soient disponibles dans l’environnement concerné.

Dans l’autre sens, la méthode [DateTimeOffset]::FromUnixTimeSeconds(1700000000) transforme une valeur numérique en objet date avec décalage UTC. On peut ensuite accéder aux propriétés ou produire une chaîne pour un journal. Il vaut mieux effectuer cette conversion dès la réception de la donnée, plutôt que de laisser circuler un nombre sans indication d’unité.

Autre usage fréquent : créer un horodatage pour distinguer les archives. Une séquence comme yyyyMMdd-HHmmss convient pour un nom lisible et triable. Si plusieurs tâches peuvent créer un fichier dans la même seconde, ajoutez des millisecondes, par exemple avec yyyyMMdd-HHmmss-fff, ou utilisez un identifiant distinct.

Attention aux méthodes de conversion implicite. PowerShell peut convertir un objet date en chaîne lorsqu’il est transmis à une commande qui attend du texte, mais cette chaîne dépend alors de la culture. Pour écrire dans un journal destiné à être analysé automatiquement, il faut choisir un format explicite et documenter si l’horodatage est en UTC.

Dans une PME qui centralise les journaux de plusieurs serveurs, la cohérence de l’heure est plus utile qu’un affichage joli. Un serveur en heure locale et un autre en UTC peuvent sembler désordonnés dans un export si le décalage n’est pas conservé. Le timestamp aide à comparer les événements, mais la synchronisation des horloges système reste nécessaire.

Culture et fuseau horaire : éviter les dates ambiguës

Get-Date utilise la culture courante pour afficher un objet date. Une date numérique peut donc changer d’apparence d’une machine à l’autre : le mois et le jour ne sont pas toujours présentés dans le même ordre, et les noms de mois dépendent de la langue. Un formatage explicite réduit ces écarts, mais ne règle pas à lui seul la question du fuseau horaire.

La culture décrit notamment les conventions d’affichage. Le fuseau, lui, situe une heure locale par rapport à UTC. Ces deux notions sont différentes : une date peut être affichée en français tout en représentant une heure locale américaine, ou être formatée avec des chiffres sans nom de mois tout en restant liée à un fuseau précis.

Une date fournie comme 2020-01-01T00:00:00 sans indicateur de fuseau peut être interprétée comme une valeur dont le type de fuseau est indéfini. La propriété Kind aide à repérer ce cas : elle peut indiquer Unspecified, Local ou Utc. Ne supposez pas qu’une chaîne sans suffixe signifie automatiquement UTC.

Dans les versions récentes, Get-Date -AsUTC permet d’interpréter la valeur comme UTC. Ce paramètre est disponible depuis PowerShell 7.1. Il peut modifier l’heure affichée par rapport à la valeur locale saisie, car une conversion de fuseau déplace l’heure tout en conservant l’instant représenté.

Pour convertir un objet existant, $dateExecution.ToUniversalTime() renvoie son équivalent UTC lorsque l’objet porte l’information nécessaire. Pour vérifier si une date locale est concernée par l’heure d’été, la méthode $dateExecution.IsDaylightSavingTime() donne un résultat booléen. Ces tests sont plus fiables que l’ajout manuel d’une heure en fonction du mois.

Les changements d’heure créent des cas délicats. Une heure locale peut ne pas exister lors du passage à l’heure d’été, ou apparaître deux fois lors du retour à l’heure standard. Pour des systèmes qui échangent des événements, stocker et transmettre des instants en UTC évite une partie de ces ambiguïtés ; l’affichage local peut intervenir ensuite pour l’utilisateur.

La culture peut également intervenir lors de l’analyse d’une date textuelle fournie à -Date. Une chaîne telle que 03/04/2026 est ambiguë si le format attendu n’est pas explicite. Dans un script exécuté sur plusieurs postes, privilégiez une représentation non ambiguë avec année, mois et jour, et contrôlez le comportement sur la version PowerShell ciblée.

Les environnements Windows anciens méritent une vérification à part. Un script PowerShell dépend de la version installée et du Windows Management Framework disponible ; avant de reprendre une commande récente sur un poste hérité, consultez le guide consacré au Windows Management Framework et à ses versions. Pour les tâches de maintenance d’anciennes installations, les guides sur la vérification d’une image ISO de Windows 7 et le téléchargement de Windows 10 rappellent aussi pourquoi il faut distinguer les outils disponibles selon le système concerné.

Dans un parc hétérogène, le test pertinent n’est pas seulement de lancer une commande dans une console. Il faut aussi vérifier le compte qui exécute la tâche planifiée, la culture du processus et le fuseau configuré sur l’hôte. Trois paramètres discrets peuvent expliquer qu’un horodatage change entre le poste de test et le serveur.

Choisir entre -Format, -UFormat et les formats standards

Le paramètre -Format utilise les modèles .NET ; -UFormat emploie des marqueurs inspirés des formats Unix, précédés du caractère %. Ils produisent tous deux une chaîne, mais leurs codes ne sont pas interchangeables. Copier un modèle trouvé dans un script shell vers PowerShell sans l’adapter est une source classique de dates incorrectes.

Avec Get-Date -UFormat '%A %m/%d/%Y %R %Z', on obtient notamment le nom complet du jour, le mois, le jour, l’année, l’heure sans secondes et un décalage de fuseau. Les significations exactes des marqueurs et leur disponibilité peuvent varier selon la version de PowerShell. Le marqueur %F, par exemple, n’est pas disponible dans Windows PowerShell 5.1.

Les marqueurs %Y, %m et %d correspondent respectivement à l’année, au mois et au jour dans plusieurs modèles courants. Cela ne signifie pas que tous les marqueurs possèdent le même comportement que sous Unix. Le numéro de semaine est un exemple de divergence : %W ne suit pas nécessairement les mêmes règles dans les deux environnements.

Pour du code destiné à plusieurs versions de PowerShell, -Format est généralement le choix le plus simple lorsque les formats .NET couvrent le besoin. Si un format Unix précis est requis, testez-le sur chaque version cible et vérifiez les résultats attendus. Une commande qui réussit sans erreur peut malgré tout produire une valeur différente de celle attendue.

Les formats prédéfinis comme FileDate et FileDateTimeUniversal réduisent le risque d’une faute de casse ou d’un modèle mal construit. Ils sont adaptés à des chemins de fichiers et distinguent les variantes locales des variantes UTC. Avant de retenir l’un d’eux, vérifiez que le lecteur comprend si le nom correspond à l’heure locale du serveur ou à l’heure universelle.

Une chaîne ISO 8601 n’est pas automatiquement une garantie de bonne conversion. Le texte doit comporter les informations nécessaires à son interprétation, notamment le décalage ou l’indicateur UTC quand l’heure n’est pas locale par convention. Pour une communication entre services, il vaut mieux convenir du format et du fuseau attendus dans le contrat de données.

Dans une chaîne interpolée, une variable DateTime peut être convertie implicitement en texte. Pour maîtriser le résultat, formatez explicitement la valeur, par exemple "Exécution : $($dateExecution.ToString('yyyy-MM-dd HH:mm:ss'))". Cette écriture évite de confondre le format d’affichage de la console avec celui du message produit.

La règle pratique est simple : un humain peut recevoir une date localisée et lisible ; un autre programme doit recevoir un format convenu, stable et documenté. Pour un journal technique partagé entre serveurs, une date UTC avec un format explicite est généralement plus exploitable qu’une chaîne dépendante de la langue de chaque machine.

FAQ

Comment obtenir une date au format ISO 8601 avec PowerShell ?

Utilisez Get-Date -Format o pour obtenir une chaîne .NET de type aller-retour. Pour construire un format ciblé, choisissez un modèle explicite comme yyyy-MM-dd’T’HH:mm:ssK et vérifiez que l’objet porte bien l’information de fuseau attendue.

Comment créer une date en chaîne de caractères pour un nom de fichier ?

Employez un modèle sans caractères interdits par le système de fichiers, par exemple Get-Date -Format ‘yyyyMMdd-HHmmss’. Ajoutez les millisecondes si plusieurs fichiers peuvent être créés pendant la même seconde.

Quelle est la différence entre -Format et -UFormat ?

-Format utilise les modèles de date et d’heure .NET, tandis que -UFormat utilise des marqueurs précédés de %. Les deux renvoient une chaîne, et leurs spécificateurs ne doivent pas être mélangés.

Comment convertir un timestamp Unix en date ?

Avec PowerShell 7.1 ou une version ultérieure, utilisez Get-Date -UnixTimeSeconds suivi du nombre de secondes. Vérifiez si la source fournit des secondes ou des millisecondes avant de lancer la conversion.

Pourquoi le résultat de Get-Date change-t-il selon la machine ?

L’affichage dépend de la culture du processus et la valeur peut être interprétée dans un fuseau différent. Pour les scripts, spécifiez le format, clarifiez le recours à UTC et testez le compte qui exécute réellement la tâche.