0
1970-01-01T00:00:00Z
946684800
2000-01-01T00:00:00Z
2147483647
2038-01-19T03:14:07Z — max for 32-bit signed int
9223372036854775807
~292 billion years — no practical overflow
86400000
60 × 60 × 24 × 1000
31536000
365 × 24 × 60 × 60 (non-leap)
2024-01-15T12:30:00Z
YYYY-MM-DDTHH:MM:SSZ — widely recommended
2024-01-15T07:30:00-05:00
YYYY-MM-DDTHH:MM:SS±HH:MM
Mon, 15 Jan 2024 12:30:00 +0000
Used in email headers and HTTP headers
2024-01-15T12:30:00.000Z
Subset of ISO 8601 with milliseconds
Mon, 15 Jan 2024 12:30:00 GMT
Used in HTTP headers (Last-Modified, Date)
01/15/2024
Ambiguous — avoid in APIs
15/01/2024
Ambiguous — avoid in APIs
2024-01-15
SQL DATE type, BigQuery, Redshift
20240115123000
Lexicographically sortable
Date.now()
Returns milliseconds since epoch
Math.floor(Date.now() / 1000)
Returns whole seconds
new Date(ts * 1000).toISOString()
Multiply by 1000 if ts is in seconds
Math.floor(new Date('2024-01-15T12:30:00Z').getTime() / 1000)import time; time.time()
Returns float with sub-second precision
from datetime import datetime, timezone datetime.fromtimestamp(ts, tz=timezone.utc)
Always pass tz=timezone.utc to avoid local timezone
from datetime import datetime, timezone
datetime.fromisoformat('2024-01-15T12:30:00+00:00').timestamp()SELECT EXTRACT(EPOCH FROM NOW())::BIGINT;
Returns whole seconds
SELECT to_timestamp(1705319400);
SELECT UNIX_TIMESTAMP();
SELECT FROM_UNIXTIME(1705319400);
time.Now().UnixNano()
Nanoseconds precision
time.Now().Unix()
SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs()
time()
Returns seconds; microtime(true) for float
date +%s
GNU/BSD date; on macOS same command works
+00:00
Coordinated Universal Time — no DST
-05:00 / -04:00
EST in winter, EDT in summer (DST)
-06:00 / -05:00
-07:00 / -06:00
-08:00 / -07:00
+00:00 / +01:00
BST (British Summer Time) in summer
+01:00 / +02:00
Germany, France, Italy, Poland, etc.
+05:30
No DST — half-hour offset
+08:00
No DST — entire country one timezone
+09:00
No DST
+10:00 / +11:00
DST in southern hemisphere summer (Oct–Apr)
+12:00 / +13:00
| Unité | Chiffres | Exemple | Plage approx. |
|---|---|---|---|
| Seconds (s) | 10 | 1705319400 | 1970 – 2286 |
| Milliseconds (ms) | 13 | 1705319400000 | 1970 – 2286 (×1000) |
| Microseconds (μs) | 16 | 1705319400000000 | Sub-second precision |
| Nanoseconds (ns) | 19 | 1705319400000000000 | Used by Go, Rust, Linux kernel |
Les timestamps Unix sont toujours en UTC. Ils ne contiennent pas d'information de fuseau horaire. C'est en fait un avantage — cela fournit un point de référence universel.
La confusion survient lors de la conversion des timestamps en dates lisibles :
const ts = 1700000000;
const date = new Date(ts * 1000);
date.toUTCString(); // "Tue, 14 Nov 2023 22:13:20 GMT"
date.toLocaleString(); // Depends on user's local time zone
date.toISOString(); // "2023-11-14T22:13:20.000Z"
Bonne pratique : Stockez et transmettez les timestamps en UTC. Convertissez en heure locale uniquement au niveau de l'affichage, au plus près de l'utilisateur.
-- Current timestamp
SELECT EXTRACT(EPOCH FROM NOW());
-- Timestamp to date
SELECT TO_TIMESTAMP(1700000000);
-- Date to timestamp
SELECT EXTRACT(EPOCH FROM '2023-11-14'::timestamp);
Si une date affiche janvier 1970, vous avez probablement passé des secondes là où des millisecondes étaient attendues (ou inversement). Vérifiez toujours quelle précision l'API attend.
Lors du stockage de timestamps en nombres à virgule flottante, vous pouvez perdre de la précision au-delà des millisecondes. Pour une précision en microsecondes ou nanosecondes, utilisez des entiers avec le multiplicateur approprié.
Les timestamps Unix ne tiennent pas compte des secondes intercalaires. Un jour Unix fait toujours exactement 86 400 secondes, même si les jours UTC réels ont occasionnellement 86 401 secondes. Pour la plupart des applications, c'est sans importance. Pour les applications scientifiques ou satellitaires, utilisez le TAI (Temps Atomique International) à la place.
Stockez les dates comme timestamps (entier ou types datetime natifs) pour un tri, une comparaison et une arithmétique efficaces. Les chaînes formatées sont plus difficiles à interroger et à trier correctement. La plupart des bases de données ont des types datetime natifs qui gèrent bien cela. Réservez le formatage en chaîne pour l'affichage et les réponses API.
Un timestamp Unix (aussi appelé heure epoch) est le nombre de secondes écoulées depuis 00:00:00 UTC le 1er janvier 1970, sans compter les secondes intercalaires. C'est un entier unique qui identifie sans ambiguïté tout moment dans le temps, indépendamment du fuseau horaire.
Les timestamps Unix traditionnels comptent les secondes entières. Les langages modernes et les APIs (JavaScript Date.now(), Java System.currentTimeMillis()) utilisent les millisecondes — 1000× plus grand — pour une précision sub-seconde. Lors de l'interopération, vérifiez toujours la magnitude : un nombre à 10 chiffres représente des secondes, à 13 chiffres des millisecondes.
Les entiers signés 32 bits peuvent représenter des timestamps jusqu'à 2 147 483 647, ce qui correspond au 19 janvier 2038 à 03:14:07 UTC. Après ce moment, les systèmes 32 bits déborderont vers des valeurs négatives. Les systèmes 64 bits peuvent représenter des dates bien au-delà de l'an 292 milliards.
En JavaScript : new Date(ts * 1000).toISOString(). En Python : datetime.fromtimestamp(ts, tz=timezone.utc).isoformat(). En SQL (PostgreSQL) : to_timestamp(ts). Le format ISO 8601 est YYYY-MM-DDTHH:MM:SSZ pour UTC, ex. 2024-01-15T12:30:00Z.