Un guide pour les développeurs sur le convertisseur de timestamp Unix

Un convertisseur de timestamp Unix est l'un de ces outils simples mais indispensables auxquels vous vous tournerez constamment en tant que développeur ou analyste de données. C'est une utilité pratique qui traduit un long nombre apparemment aléatoire en une date et une heure que nous pouvons réellement comprendre. Cette traduction est cruciale lorsque vous fouillez dans les journaux système, travaillez avec des API ou interrogez des bases de données où le temps est stocké dans ce format super efficace.

Qu'est-ce qu'un timestamp Unix et pourquoi est-il important

Avant de pouvoir vraiment apprécier un bon convertisseur, il faut comprendre ce que ce nombre représente réellement. En son cœur, un timestamp Unix n'est qu'un compteur de secondes en progression. Il suit le nombre total de secondes écoulées depuis le 00:00:00 UTC le 1er janvier 1970. Ce moment précis dans le temps est universellement connu sous le nom d'"epoch Unix".

Pourquoi utiliser cette méthode ? Simplicité et efficacité. Stocker le temps sous la forme d'un seul entier est bien plus compact et performant qu'une chaîne de caractères verbeuse comme "vendredi 1er janvier 2021 00:00:00 GMT". Cela le rend parfait pour quelques domaines clés :

• Stockage en base de données : Les timestamps sont petits, ce qui permet un indexage et des requêtes rapides. C'est un gain énorme pour les performances.
• Données d'API : Envoyer un seul aller-retour de nombre est bien moins gourmand en bande passante que l'envoi d'une date complète sous forme de chaîne, ce qui entraîne des temps de réponse plus rapides.
• Fichiers journaux (logs) : Lorsque vous analysez des logs provenant de dizaines de systèmes différents, disposer d'un timestamp uniforme et indépendant de la langue est une bénédiction.
• Calculs : Vous devez savoir combien de temps a duré un processus ? Soustrayez simplement le timestamp de début du timestamp de fin. C'est un simple calcul d'entiers.

Secondes vs. Millisecondes et au-delà

Le timestamp Unix classique est un nombre à 10 chiffres représentant les secondes. Mais avec l'évolution technologique, le besoin d'une mesure du temps plus granulaire a augmenté. C'est là que vous commencerez à voir des timestamps de longueurs différentes, et c'est un obstacle courant.

Voici un aperçu rapide de ce que vous rencontrerez généralement. Confondre l'un avec l'autre est une erreur classique de "décalage de mille" qui peut mener à des bugs très déroutants.

Formats courants de timestamp Unix en un coup d'œil

Unité	Nombre de chiffres	Cas d'utilisation typique	Valeur exemple (pour le même instant)
Secondes	10	Standard pour la plupart des systèmes backend, des bases de données et des API.	1609459200
Millisecondes	13	Très courant dans les technologies web, en particulier JavaScript.	1609459200000
Microsecondes	16	Utilisé dans le trading à haute fréquence ou l'informatique scientifique.	1609459200000000

Bien comprendre ces formats est essentiel. Si un outil attend des secondes et que vous lui fournissez des millisecondes, vous obtiendrez une date dans plusieurs milliers d'années. C'est une erreur que nous avons tous commise à un moment ou un autre !

Le fameux problème de l'an 2038

La simplicité élégante du timestamp Unix a également créé une bombe à retardement : le "problème de l'an 2038". Sur les systèmes 32 bits plus anciens, les timestamps étaient stockés sous forme d'entier signé 32 bits. Le problème est que ce type d'entier a un plafond – il ne peut pas contenir un nombre supérieur à 2,147,483,647.

Le 19 janvier 2038 à 03:14:07 UTC, le nombre de secondes écoulées depuis l'époque dépassera cette limite. Lorsque cela se produira, l'entier « bouclera » et deviendroit un nombre négatif. Cela amènerait les systèmes vulnérables à interpréter la date comme étant revenue en 1901, ce qui pourrait entraîner le blocque de milliards de périphériques anciens encore en circulation. Vous pouvez obtenir plus d'informations sur l'époque Unix et son impact auprès des experts de StrongDM.

Heureusement, la majorité d'entre nous n'ont pas à s'en soucier quotidiennement. L'écrasante majorité des systèmes modernes utilisent désormais des entiers 64 bits pour la gestion du temps. Un entier 64 bits est si vaste qu'il ne débordera pas avant encore 292 milliards d'années, résolvant ainsi le problème de manière définitive.

Cela reste cependant un morceau d'histoire informatique fascinant et une connaissance essentielle si vous vous retrouvez un jour à travailler sur des systèmes embarqués anciens ou des bases de code obsolètes. Comprendre ces fondamentaux rend n'importe quel convertisseur de timestamp Unix bien plus puissant entre vos mains.

Des conversions sans effort dans votre navigateur

Bien que l'utilisation d'une commande terminal ou d'un extrait de code fonctionne, ce n'est pas toujours le moyen le plus rapide d'obtenir des résultats. Parfois, vous avez simplement besoin d'une réponse tout de suite, sans briser votre concentration ni changer de fenêtre. C'est là qu'un bon outil basé sur navigateur prouve vraiment sa valeur, en particulier un convertisseur de timestamp Unix dédié qui vit directement dans votre navigateur.

La véritable magie réside dans le maintien du flux de travail. Imaginez : vous explorez une réponse API dans les outils de développement de votre navigateur et repérez un timestamp. Au lieu d'ouvrir un autre onglet ou de lancer un terminal, vous utilisez un raccourci clavier rapide, collez le nombre et obtenez votre réponse instantanément. C'est le genre de flux de travail fluide que vous offrent des outils comme ShiftShift Extensions, qui regroupent de nombreuses utilités pratiques dans une seule palette de commandes.

Obtenez des réponses instantanées avec un raccourci clavier

Tout repose sur la vitesse. Avec un outil comme ShiftShift, un double appui rapide sur la touche Maj (ou Cmd+Shift+P sur Mac) fait apparaître une barre de commandes. Il suffit de commencer à taper « timestamp » et le convertisseur apparaît. Collez votre valeur et vous obtenez immédiatement une date lisible par un humain.

Voici à quoi cela ressemble – la palette de commandes est prête et attend de convertir un timestamp directement par-dessus votre page actuelle.

Le meilleur, c'est son intégration sans encombre. Le convertisseur n'est qu'un des nombreux outils disponibles dans la même superposition, vous n'avez donc jamais besoin de quitter ce que vous êtes en train de faire.

Cette approche est une bouée de sauvetage pour les développeurs, les testeurs et tous ceux qui vivent littéralement dans leur navigateur. De plus, la conversion se fait entièrement sur votre machine. Les données sensibles des journaux ou des réponses API ne quittent jamais votre ordinateur, ce qui est un énorme avantage pour la confidentialité.

Pouvoir convertir un timestamp, reformatage un bloc JSON désordonné, puis calculer une différence de temps – le tout depuis la même interface – fait gagner un temps précieux. Cela transforme un processus maladroit utilisant plusieurs outils en une action unique et fluide.

Bien plus qu'un outil à usage unique

Un excellent utilitaire en navigateur est rarement un outil isolé ; il fait partie d'une boîte à outils complète. Vous vous surprendrez souvent à utiliser le convertisseur de timestamp aux côtés d'autres fonctions.

Par exemple, vous pourriez le coupler avec :

• Un formateur JSON ou SQL pour nettoyer du code avant d'extraire le timestamp.
• Une calculatrice intégrée pour effectuer des calculs rapides sur des valeurs d'époque. (Vous pouvez vous amuser avec un outil similaire sur la page de la calculatrice ShiftShift pour voir comment cela fonctionne).
• Un outil de comparaison de texte pour repérer les différences entre deux réponses API, timestamps compris.

Disposer de tous ces éléments essentiels au même endroit crée un flux de travail bien plus rapide et cohérent. Il ne s'agit pas seulement de commodité – il s'agit d'éliminer toutes ces petites interruptions répétitives qui s'accumulent et tuent votre productivité au fil d'une journée.

Conversions pratiques de timestamps en code

Si vous êtes développeur, vous savez que jongler avec les timestamps fait partie du métier. Mais soyons honnêtes, la syntaxe n'est jamais tout à fait la même d'un langage à l'autre. Cette section est votre aide-mémoire de référence, remplie d'extraits de code que vous pouvez récupérer et utiliser immédiatement pour les plateformes sur lesquelles vous travaillez réellement. Fini le temps passé à fouiller dans les vieux fils Stack Overflow – voici des exemples pratiques pour vous lancer.

Que vous manipuliez des données sur un front-end web, écriviez un script Python ou interrogiez une base de données, la conversion du temps epoch est une compétence fondamentale. Nous allons passer en revue les scénarios les plus courants, depuis la conversion d'un entier epoch en une chaîne lisible jusqu'à l'opération inverse.

Conversion des horodatages en JavaScript

L'objet Date de JavaScript est ici votre principal outil, mais il présente une particularité majeure qui piège souvent les développeurs : il opère en millisecondes, et non en secondes. Il s'agit d'une source classique de bugs lorsque votre front-end communique avec un back-end qui utilise des horodatages standard à 10 chiffres, basés sur les secondes.

Pour convertir correctement un horodatage Unix standard (en secondes) en un objet Date, vous devez le multiplier par 1000.

// A standard 10-digit Unix timestamp (in seconds)
const unixTimestamp = 1672531200;

// Convert to milliseconds, then create a Date object
const dateObject = new Date(unixTimestamp * 1000);

// Format into a readable UTC string
// Output: Sun, 01 Jan 2023 00:00:00 GMT
console.log(dateObject.toUTCString());

Besoin de l'horodatage actuel ? Date.now() vous le fournit en millisecondes. Souvenez-vous simplement de diviser par 1000 et d'arrondir à l'inférieur avant de renvoyer un horodatage standard à 10 chiffres à une API.

Gestion des conversions avec Python

Côté serveur, le module datetime de Python est un outil puissant. Il est incroyablement flexible et offre un support fantastique pour les conversions prenant en compte les fuseaux horaires, ce qui en fait un choix fiable pour les services qui doivent gérer le temps avec précision dans différentes régions.

Voici la méthode simple pour convertir un horodatage avec la bibliothèque datetime :

import datetime

Un horodatage Unix standard à 10 chiffres

unix_timestamp = 1672531200

Conversion de l'horodatage en un objet datetime

datetime_obj = datetime.datetime.fromtimestamp(unix_timestamp)

Formatage en une chaîne lisible et claire

Sortie : 2023-01-01 00:00:00

print(datetime_obj.strftime('%Y-%m-%d %H:%M:%S'))
Cette approche simple vous offre un moyen propre et fiable de gérer le temps epoch dans vos applications Python. Et si vous travaillez avec des structures de données complexes comme le JSON contenant des horodatages, vous pourriez trouver notre guide sur l'utilisation d'un formateur JSON utile pour le débogage.

Conversions dans les bases de données avec SQL

Les bases de données stockent souvent le temps sous forme d'horodatages Unix car c'est efficace. La bonne nouvelle est que la plupart des dialectes SQL disposent de fonctions intégrées pour gérer ces conversions directement dans vos requêtes. C'est bien plus efficace que d'extraire des horodatages entiers bruts et de les convertir dans le code de votre application.

L'horodatage Unix est presque universel, utilisé dans plus de 90% des langages de programmation — du Date.now() de JavaScript au time.time() de Python — alimentant des billions d'opérations quotidiennes. Obtenir les fuseaux horaires correctement est essentiel ; un solide convertisseur d'horodatage unix peut gérer plus de 400 zones IANA, ce qui aide à prévenir les erreurs dans environ 62% des applications mondiales qui ne gèrent pas explicitement les fuseaux horaires. Vous pouvez trouver plus de détails sur l'adoption mondiale de ces outils sur Fossa.

Pour les développeurs, pouvoir formater du SQL, convertir des horodatages et calculer des différences d'epoch sans jamais quitter votre machine est un énorme gain de productivité. Cette approche locale reste également conforme aux normes modernes de confidentialité des données comme le RGPD et le CCPA.

Exemple avec MySQL

Dans MySQL, la fonction FROM_UNIXTIME() est celle que vous utiliserez le plus. Elle prend un entier epoch et le convertit élégamment en un format standard DATETIME.

SELECT FROM_UNIXTIME(1672531200);
-- Retourne : '2023-01-01 00:00:00'
Pour faire l'inverse — d'une chaîne de date à un horodatage epoch — utilisez simplement UNIX_TIMESTAMP().

SELECT UNIX_TIMESTAMP('2023-01-01 00:00:00');
-- Retourne : 1672531200

Exemple PostgreSQL

PostgreSQL utilise une fonction légèrement différente mais tout aussi puissante : to_timestamp(). Cette fonction convertit directement un horodatage Unix en une valeur TIMESTAMP WITH TIME ZONE .

SELECT to_timestamp(1672531200);
-- Retourne : 2023-01-01 00:00:00+00
Étant conscient des fuseaux horaires par défaut, c'est un choix très robuste pour les applications destinées à un public mondial où la précision temporelle est non négociable.

Maîtriser les conversions d'horodatages dans le terminal

Si vous vivez dans la ligne de commande, passer à un navigateur ou à une interface graphique pour une rapide conversion d'horodatage est un véritable tueur de flux de travail. Cela casse simplement votre concentration. La bonne nouvelle est que vous n'avez pas à le faire ; Linux et macOS disposent d'outils natifs puissants pour gérer ces conversions sans jamais quitter le terminal.

L'utilitaire de référence pour cela est la modeste commande date. Elle est présente sur pratiquement tous les systèmes de type Unix, mais il y a un piège : la syntaxe pour l'utiliser comme convertisseur d'horodatage unix diffère entre Linux (GNU) et macOS (BSD). Connaître la différence est la clé pour réussir à chaque fois.

Conversion des horodatages sous Linux

Sous Linux, la syntaxe est simple et facile à retenir. Vous utilisez simplement le drapeau -d pour spécifier la date, mais vous devez indiquer que vous fournissez un horodatage epoch en le préfixant du symbole @.

Supposons que vous exploriez des journaux et que vous repériez l'horodatage 1704067200. Pour voir ce que cela signifie réellement, vous exécuteriez ceci :

date -d @1704067200

Immédiatement, vous obtiendrez une date lisible par l'homme, quelque chose comme Mon Jan 1 00:00:00 UTC 2024. Vous pouvez également nettoyer cette sortie avec votre propre format personnalisé.

date -d @1704067200 +"%Y-%m-%d %H:%M:%S"

Sortie : 2024-01-01 00:00:00

Astuce Pro : Cette commande devient un véritable outil puissant lorsque vous commencez à injecter d'autres commandes dans son flux. Vous pouvez grep un horodatage à partir d'un énorme fichier journal et le transmettre directement à date pour une conversion instantanée. Cela transforme une tâche de débogage en plusieurs étapes en une seule ligne de commande élégante.

Gestion des conversions sous macOS

Maintenant, si vous exécutez cette même commande Linux sur un Mac, cela va générer une erreur. La version BSD de date utilisée par macOS requiert le drapeau -r à la place, et elle n'a pas besoin du préfixe @.

Voici comment vous convertiriez le même horodatage sur un Mac :

date -r 1704067200

Comme pour la version Linux, vous pouvez ajouter des options de formatage pour obtenir la sortie exacte que vous souhaitez.

date -r 1704067200 +"%Y-%m-%d %T %Z"

Sortie : 2024-01-01 00:00:00 UTC

Cette légère différence est un obstacle classique pour quiconque saute fréquemment entre Linux et macOS. Mémoriser les deux versions vous évitera bien des maux de tête à l'avenir.

Une fois ces commandes maîtrisées, vous pouvez intégrer les conversions d'horodatages directement dans vos scripts shell et analyses de journaux. C'est une petite compétence, mais elle contribue à des gains de productivité importants, vous maintenant dans la zone et concentré sur le travail qui compte.

Pièges courants des horodatages et comment les éviter

Travailler avec des horodatages Unix semble simple en surface, mais quelques erreurs classiques peuvent mener à des bogues véritablement exaspérants. Ces problèmes ont la fâcheuse habitude d'apparaître loin de là où l'erreur s'est réellement produite, ce qui en fait un véritable casse-tête à déboguer. Considérez cette section comme votre guide de terrain pour repérer et contourner les pièges d'horodatage les plus courants que j'ai pu observer au fil des années.

La confusion Secondes vs. Millisecondes

De loin, l'erreur la plus fréquente est de confondre secondes et millisecondes. Un horodatage Unix standard est un entier à 10 chiffres représentant le nombre de secondes écoulées depuis l'époque. Mais de nombreux systèmes, en particulier dans le monde JavaScript, travaillent avec un horodatage à 13 chiffres pour les millisecondes. Lorsqu'une application front-end transmet une valeur en millisecondes à un back-end qui attend des secondes, les choses déraillent.

Pour unix timestamp convertor, ce nombre à 13 chiffres ressemble à une date située des milliers d'années dans le futur. Cela peut silencieusement corrompre la validation des données, la logique de planification et tous les enregistrements historiques que vous essayez de conserver. C'est le genre de corruption de données subtile que vous pourriez ne pas remarquer pendant des semaines.

Le Piège du Fuseau Horaire

Un autre piège qui attrape même les développeurs expérimentés est la gestion des fuseaux horaires. Par définition, un horodatage Unix est toujours exprimé en Temps Universel Coordonné (UTC). Il représente un instant unique et universel, totalement indépendant de la localisation. Le piège se referme lorsque vous oubliez ce fait et supposez qu'un horodatage reflète l'heure locale d'un utilisateur.

Cette erreur se produit généralement lorsque vous convertissez un horodatage en une date lisible sans spécifier de fuseau horaire. Votre système utilise souvent par défaut l'heure locale du serveur, entraînant le chaos. Un utilisateur à New York pourrait voir une heure destinée à quelqu'un à Londres, mais décalée de plusieurs heures.

La règle d'or est simple : traitez toujours les horodatages comme UTC dans votre backend. Stockez-les en UTC, traitez-les en UTC, et ne les convertissez en heure locale de l'utilisateur que côté front-end, au moment exact de l'affichage.

Dépannage des Erreurs Courantes de Conversion d'Horodatage

Lorsque les choses tournent mal, les symptômes peuvent être déroutants. Voici un tableau de référence rapide que j'ai compilé à partir de l'expérience pour vous aider à diagnostiquer et corriger les problèmes les plus courants sur le vif.

Symptôme	Cause Probable	Solution
La date est en l'année 52361 ou dans un autre futur lointain.	Millisecondes vs Secondes. Vous passez un horodatage de 13 chiffres (millisecondes) à une fonction qui attend un horodatage de 10 chiffres (secondes).	Divisez l'horodatage par 1000 avant le traitement. Validez toujours le nombre de chiffres des horodatages entrants.
L'heure est décalée de quelques heures, mais la date est correcte.	Mauvaise Gestion du Fuseau Horaire. L'horodatage a été converti en utilisant l'heure locale du serveur au lieu de celle de l'utilisateur ou de l'UTC.	Assurez-vous que toutes les conversions spécifient explicitement le fuseau horaire cible. Ne convertissez en heure locale que côté client.
La date est bloquée au 1er janvier 1970.	Horodatage Invalide ou Nul. La valeur de l'horodatage est probablement 0, null, ou undefined.	Ajoutez une vérification pour vous assurer que l'horodatage est un entier positif valide avant de tenter une conversion. Prévoyez une valeur par défaut.
Obtention de "Invalid Date" ou d'une erreur NaN.	Type de Données Incorrect. L'horodatage est traité comme une chaîne ou un autre type non numérique alors qu'un nombre est requis.	Analysez explicitement l'horodatage en tant qu'entier (parseInt() en JS, int() en Python) avant de l'utiliser dans des fonctions de date.

N'oubliez pas qu'une vérification rapide sur l'entrée peut vous faire gagner des heures de débogage par la suite.

Éviter l'Ambiguïté avec les Formats Standard

S'appuyer sur des horodatages entiers bruts lors du transfert de données entre systèmes peut être une source de confusion. C'est pourquoi la standardisation sur un format universel de chaîne comme ISO 8601 (2022-05-17T12:00:00Z) est une telle bonne démarche défensive. Convertir les horodatages Unix (par exemple, 1652905200) en un format clair et auto-documenté comme celui-ci aide à prévenir les erreurs dans environ 37% des appels d'API inter-fuseaux horaires.

Étant donné que 72% des entreprises du Fortune 500 utilisent des horodatages Unix pour l'analyse des journaux, où une seule erreur peut coûter plus de $10,000 par heure d'arrêt, la précision est primordiale. Vous pouvez en savoir plus sur l'utilisation du temps epoch dans différentes industries sur EpochConverter.

Pour ceux qui gèrent des bases de données, une gestion cohérente des horodatages est tout aussi cruciale. Si vous vous trouvez souvent à lutter avec différents formats d'horodatages dans votre base de données, notre guide sur l'utilisation d'un puissant formatageur SQL peut vous aider à garder vos requêtes propres et prévisibles.

Cet arbre de décision vous aide à choisir la bonne commande pour votre système d'exploitation, évitant les erreurs de syntaxe lorsque vous avez besoin d'une conversion rapide.

Le diagramme de flux ci-dessus montre clairement la différence de syntaxe cruciale entre la commande date sous Linux (-d @...) et macOS (-r ...) — un piège courant pour les développeurs travaillant dans des environnements différents.

Pour sécuriser votre code, implémentez toujours des vérifications pour valider la longueur d'un horodatage entrant. Une simple fonction qui vérifie une valeur de 10 chiffres (secondes) ou 13 chiffres (millisecondes) peut attraper ces erreurs avant qu'elles n'infiltrent la logique de votre application.

Questions courantes sur les horodatages Unix

Une fois que vous maîtrisez les horodatages Unix, quelques questions pratiques surgissent presque toujours. J'ai vu des développeurs de tous niveaux trébucher sur celles-ci, donc clarifions les plus courantes que vous rencontrerez dans votre travail quotidien.

Pourquoi tant d'API utilisent-elles des horodatages au lieu de chaînes ISO 8601 ?

Cela revient vraiment à l'efficacité pure. Un horodatage Unix n'est qu'un seul nombre, ce qui le rend incroyablement compact par rapport à une chaîne comme '2023-10-27T10:00:00Z'. Cette taille réduite signifie moins de données à transmettre, ce qui économise la bande passante et peut accélérer les réponses de l'API.

Ils sont également totalement indépendants du langage. Il n'y a pas d'ambiguïté, pas de subtilités de parsing, et pas de formatage régional à gérer. Pour une machine, traiter des nombres est toujours plus rapide que parser des chaînes, donc tout calcul de date — comme déterminer le temps écoulé entre deux événements — est moins coûteux en termes de calcul. Pour les systèmes haute performance, cette simplicité est un avantage énorme.

Quelle est la bonne façon de gérer les fuseaux horaires ?

C'est la grande question. Voici la règle d'or : Un horodatage Unix est toujours, toujours en UTC. Il n'a pas de concept de fuseau horaire intégré. C'est simplement un compteur brut de secondes depuis l'époque.

Les fuseaux horaires ne comptent que lorsque vous devez afficher cet horodatage à un humain.

Mon conseil ? Utilisez UTC pour tout côté serveur. Stockez-le dans votre base de données en tant qu'horodatage UTC, passez-le dans vos API en UTC, et effectuez toute votre logique côté serveur en UTC. La seule fois où vous devriez le convertir vers un fuseau horaire local est côté front-end, juste avant de l'afficher à l'utilisateur. Cette seule pratique vous évitera tout un univers de bugs liés aux fuseaux horaires et à l'heure d'été.

Dois-je encore m'inquiéter du problème de l'an 2038 ?

Pour la plupart des nouveaux projets, probablement pas. Le « problème de l'an 2038 » est un héritage des anciens systèmes qui utilisaient un entier signé 32 bits pour stocker l'horodatage. Une fois que ce nombre devient trop grand, il dépasse la capacité et devient négatif, renvoyant les dates à 1901.

Heureusement, presque tous les systèmes modernes — des systèmes d'exploitation aux bases de données — sont depuis longtemps passés aux entiers 64 bits. Cela recule considérablement le problème (de milliards d'années, en fait), au point qu'il n'est plus une préoccupation pratique pour nous.

Cela dit, si vous maintenez un système ancien ou travaillez avec du matériel embarqué (pensez aux appareils IoT), c'est définitivement quelque chose à garder à l'esprit. Connaissez toujours l'architecture sur laquelle vous construisez.

Comment puis-je convertir rapidement un horodatage dans Excel ou Google Sheets ?

Vous n'avez pas besoin d'extraire vos données vers un convertisseur d'horodatage Unix séparé pour cela. Une simple formule suffit. En supposant que votre horodatage soit dans la cellule A1 :

• Pour les horodatages en secondes (10 chiffres) : =A1 / 86400 + DATE(1970,1,1)
• Pour les horodatages en millisecondes (13 chiffres) : =A1 / 86400000 + DATE(1970,1,1)

Il vous suffit d'entrer cette formule, puis de formater la cellule en « Date » ou « Date Heure ». C'est un véritable salut lorsque vous analysez rapidement des exports de données et ne voulez pas perdre le fil.

---

Fatigué de constamment basculer entre votre éditeur, la ligne de commande et une douzaine d'onglets de navigateur pour des tâches simples ? La suite ShiftShift Extensions intègre un puissant convertisseur d'horodatage Unix, un formateur JSON, un embellisseur SQL et bien plus encore directement dans votre navigateur. Tout ce dont vous avez besoin est à portée de raccourci clavier.

Obtenez ShiftShift Extensions et simplifiez votre flux de travail dès aujourd'hui sur https://shiftshift.app