Unix Timestamp : ce que c'est, conversion et stockage dans le développement mobile

Qu'est-ce que Unix Timestamp ?

Unix Timestamp (également connu sous le nom de POSIX time, Epoch time ou Unix time) est un système de mesure du temps qui définit le nombre de secondes écoulées depuis le 1er janvier 1970 00:00:00 UTC (l'époque Unix). Cette date a été choisie comme point de départ pour le système d'exploitation Unix, et le format est ensuite devenu le standard de facto pour représenter le temps dans les systèmes informatiques. Le timestamp ne tient pas compte des secondes intercalaires — chaque minute est comptée comme 60 secondes, bien que le Service international de la rotation terrestre ajoute parfois une seconde supplémentaire pour corriger le temps atomique.

L'époque Unix : pourquoi 1970 ?

Le choix du 1er janvier 1970 est lié à l'histoire du système d'exploitation Unix. Les développeurs Ken Thompson et Dennis Ritchie ont sélectionné cette date comme un point de départ rond et simple — elle était suffisamment précoce pour couvrir toutes les dates possibles, et suffisamment tardive pour que le temps puisse être stocké dans un entier signé de 32 bits. Initialement, le temps était mesuré en soixantièmes de seconde, puis en ticks (1/60 de seconde), et ce n'est qu'à la septième édition d'Unix (V7, 1979) que le format s'est stabilisé comme un nombre entier de secondes. Selon The Open Group Base Specifications (édition 8, 2024), les systèmes compatibles POSIX sont tenus de prendre en charge ce format.

Comment fonctionne Unix Timestamp

Le principe de fonctionnement du Unix Timestamp repose sur un simple compteur : chaque jour qui passe ajoute 86 400 secondes à la valeur. Par exemple, le timestamp 1 720 000 000 correspond à une date au milieu de l'année 2024 — la conversion exacte peut être effectuée en divisant par le nombre de secondes dans un jour, une heure et une minute. Cette approche rend le timestamp idéal pour le stockage machine : c'est un nombre entier qui occupe 4 octets (entier 32 bits) ou 8 octets (long 64 bits) et prend en charge la comparaison directe — un timestamp plus grand = une date plus tardive.

Mathématiques de conversion

Un jour = 86 400 secondes (24 x 60 x 60). Une heure = 3 600 secondes. Pour convertir un timestamp en date, il faut calculer séquentiellement le nombre de jours, d'heures, de minutes et de secondes depuis l'époque. La conversion inverse — convertir une date en jours depuis 1970-01-01, puis multiplier par 86 400 et ajouter le décalage UTC. En Java et Kotlin, ces calculs sont déjà implémentés dans les classes standard java.time.Instant et java.util.Date, ce qui évite au développeur d'effectuer des calculs manuels.

        // Obtenir Unix Timestamp en secondes
val seconds = System.currentTimeMillis() / 1000

// Convertir le timestamp en date via java.time
val instant = Instant.ofEpochSecond(seconds)
val localDate = instant.atZone(ZoneId.of("Europe/Moscow")).toLocalDate()

// Inverse : date en timestamp
val date = LocalDate.of(2026, 7, 21)
val ts = date.atStartOfDay(ZoneOffset.UTC).toEpochSecond()

Conversion de Unix Timestamp en date et vice-versa

La conversion d'un Unix Timestamp en une date lisible par l'homme est l'une des opérations les plus courantes dans le développement mobile. Sous Android, plusieurs méthodes de conversion sont disponibles selon la version minimale de l'API : pour API 26+, il est recommandé d'utiliser java.time.Instant, pour les versions plus anciennes, on utilise java.util.Date et java.text.SimpleDateFormat. Il est important de se rappeler qu'Android et la JVM utilisent les millisecondes par défaut, pas les secondes — si un timestamp est reçu du serveur en secondes, il doit être multiplié par 1000 avant d'être passé aux constructeurs standard.

Conversion avec fuseau horaire

L'un des principaux avantages du Unix Timestamp est l'indépendance par rapport à l'emplacement. Le serveur renvoie toujours le timestamp en UTC, et la conversion en date et heure locales est effectuée côté client. En Kotlin, on utilise ZonedDateTime avec le ZoneId approprié — celui du système ou celui sélectionné par l'utilisateur. Si une application affiche l'heure dans différents fuseaux horaires (par exemple, pour les voyageurs), le timestamp élimine la nécessité de transmettre le fuseau horaire depuis le serveur — un seul marqueur temporel suffit.

// Convertir avec le fuseau horaire de l'utilisateur
fun formatTimestamp(seconds: Long, zoneId: ZoneId): String {
    val instant = Instant.ofEpochSecond(seconds)
    val formatter = DateTimeFormatter
        .ofPattern("dd.MM.yyyy HH:mm:ss")
    return formatter.format(instant.atZone(zoneId))
}

// Exemple : timestamp = 1720000000, zone = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

Le problème de l'an 2038

Le problème de l'an 2038 (Y2K38) est une limitation fondamentale du stockage de Unix Timestamp sous forme d'entier signé 32 bits. La valeur maximale d'un entier signé 32 bits est 2 147 483 647, ce qui correspond au 19 janvier 2038 à 03:14:07 UTC. Après cette date, la valeur déborde et devient un nombre négatif, provoquant des défaillances dans les systèmes utilisant time_t 32 bits. Le problème est similaire au célèbre Y2K, mais affecte principalement les systèmes embarqués, les anciennes versions d'Android et les appareils IoT avec architecture 32 bits.

Échelle du problème

Selon la Linux Foundation (2025), environ 15% des appareils Linux dans les segments industriel et IoT utilisent encore des builds 32 bits. Pour les appareils Android, le risque est plus faible — la plupart des smartphones modernes fonctionnent sur des processeurs 64 bits (ARM64), mais les modèles anciens avec Android 4.x et inférieur peuvent utiliser time_t 32 bits. La solution est la migration vers time_t 64 bits, qui est sûr jusqu'à 292 milliards d'années. Depuis Android 5.0 (API 21), tous les appareils utilisent le temps 64 bits au niveau du noyau. Les développeurs d'applications mobiles n'ont qu'à stocker le timestamp en type Long (64 bits) pour éviter le problème au niveau de l'application.

Travailler avec Unix Timestamp sous Android

Dans le développement Android, la gestion correcte du Unix Timestamp est essentielle pour la synchronisation des données, l'affichage des heures de réception des messages, le calcul des délais d'attente et la planification des notifications. L'appel système System.currentTimeMillis() renvoie l'heure actuelle en millisecondes depuis l'époque Unix — c'est la source de temps la plus précise disponible sur l'appareil. Pour les requêtes réseau, on utilise généralement le Unix Timestamp en secondes, car la plupart des REST API et des bases de données fonctionnent en secondes.

Pratiques recommandées

N'utilisez jamais System.currentTimeMillis() pour mesurer des intervalles — à cet effet, il existe System.nanoTime(), qui est monotone et n'est pas affectée par les changements d'horloge de l'utilisateur. Pour l'affichage de l'heure, stockez toujours le timestamp en UTC et convertissez-le dans le fuseau horaire local côté interface utilisateur. Lorsque vous travaillez avec des bases de données (SQLite, Room), utilisez le type INTEGER et stockez le timestamp en secondes — cela occupe 8 octets (Long) et prend en charge le tri natif SQL. Pour la sérialisation JSON, il est recommandé d'envoyer le timestamp sous forme de nombre (Long) plutôt que de chaîne — c'est plus compact et s'analyse plus rapidement.

// Mesure correcte du temps d'exécution
val start = System.nanoTime()
// ... opération ...
val elapsed = System.nanoTime() - start
val seconds = elapsed / 1_000_000_000.0

// Stocker dans Room (Entity)
@Entity
data class Message(
    @PrimaryKey val id: Long,
    val text: String,
    val createdAt: Long // Unix Timestamp en secondes
)

Gestion du temps serveur

Lors de la réception d'un Unix Timestamp du serveur, vérifiez toujours l'unité de mesure : certaines API renvoient des millisecondes (compatibles JavaScript), d'autres renvoient des secondes (standard POSIX). L'accord sur les unités doit être documenté dans les spécifications de l'API. Dans la réponse du serveur, le timestamp peut être passé sous forme de Long (nombre JSON) ou de String (ISO 8601). Pour le débogage, ajoutez une fonction utilitaire qui affiche le timestamp dans un format lisible par l'homme — cela simplifie la vérification des marqueurs temporels pendant le développement.

Stockage des marqueurs de temps dans les bases de données

Le choix du format de stockage du temps dans une base de données affecte directement les performances des requêtes, la complexité du code et la précision de la gestion des fuseaux horaires. Unix Timestamp est le format le plus efficace pour les bases de données relationnelles : il est stocké sous forme d'entier (4 ou 8 octets), prend en charge l'indexation et permet un tri rapide. Contrairement aux chaînes ISO 8601, le timestamp ne nécessite pas d'analyse pour le tri et occupe moins d'espace dans un index. Pour Room et SQLite, il est recommandé de stocker le timestamp en INTEGER et d'utiliser un index sur la colonne de temps.

Recommandations pour les projets mobiles

Pour les applications Android utilisant la bibliothèque Room, il est recommandé de stocker les timestamps en Long (64 bits) et d'utiliser un TypeConverter pour la conversion automatique entre Long et Date ou Instant. Lors des requêtes à la base de données, utilisez les opérateurs de comparaison (>, <, BETWEEN) — ils fonctionnent nativement avec les types entiers. Pour la mise en cache de données nécessitant un tri temporel (par exemple, une liste de messages), créez toujours un index sur la colonne de timestamp — cela accélérera les requêtes avec ORDER BY de plusieurs ordres de grandeur avec de grands volumes de données.