date -d @1787043600 prints the date for an epoch timestamp, and date -u -d '2026-08-18 09:00:00' +%s goes back the other way. Two details decide whether this works for you: macOS uses -r instead of -d @, and a millisecond timestamp has to be divided by 1000 or date rejects it outright.
1. Timestamp to date
$ clai convert 1787043600 to a date→ date -d @1787043600Tue Aug 18 09:00:00 UTC 2026
The @ in front of the number is mandatory — it tells date these are seconds since 1970 rather than a date string. The result is in the machine's timezone.
2. Explicitly in UTC
$ clai show 1787043600 in UTC→ date -u -d @1787043600Tue Aug 18 09:00:00 UTC 2026
-u pins the output to UTC regardless of how the machine is configured. In an incident thread that is the only way to stop arguing about whose hour it was.
3. In a specific timezone
$ clai show that time in Berlin→ TZ=Europe/Berlin date -d @1787043600Tue Aug 18 11:00:00 CEST 2026
A TZ in front of the command applies to that command only. Use IANA names (Europe/Berlin, America/New_York) rather than abbreviations like CEST, which are ambiguous.
4. Back again: date to timestamp
$ clai convert 18 august 2026 09:00 UTC to unix time→ date -u -d '2026-08-18 09:00:00' +%s1787043600
+%s is the output format for "seconds since the epoch". Without -u the date string is parsed in the machine's timezone and you get a different number.
5. As ISO 8601
$ clai print the timestamp in ISO format→ date -u -Is -d @17870436002026-08-18T09:00:00+00:00
-Is is short for --iso-8601=seconds. Nearly every programming language parses this format without extra effort.
6. A millisecond timestamp
$ clai convert the millisecond timestamp 1787043600123→ ms=1787043600123; date -u -d @$((ms/1000)) +"%F %T.$((ms%1000))"2026-08-18 09:00:00.123
JavaScript, Java and most APIs hand you milliseconds. Integer division gives the seconds, and the remainder supplies the fractional part that date won't produce on its own.
Gotchas
- date does not understand milliseconds. Verified:
date -u -d @1787043600123answersdate: invalid date '@1787043600123'. The number isn't from the far future, it's 2026 multiplied by a thousand. - macOS uses a different flag. GNU:
date -d @1787043600. BSD and macOS:date -r 1787043600. A script written on Linux silently prints today's date or errors out on a Mac — installcoreutilsfrom Homebrew and callgdateif you need one syntax everywhere. - Without
-uyou're converting into someone else's timezone. The same timestamp on a UTC server and on a laptop in Berlin is two hours apart, as above. In incident reports, always pin the zone.
Related questions
How do I get the current timestamp? date +%s. For milliseconds, GNU has date +%s%3N; BSD has no such format.
How do I get the difference between two dates? Convert both to seconds and subtract: between 11 and 18 August 2026 that is 604800 seconds, exactly one week.
What is the year 2038 problem? A signed 32-bit seconds field overflows on 19 January 2038. On 64-bit systems and in modern languages it's settled, but it still turns up in old binary formats.
See also
- sed -i doesn't work on macOS
- journalctl: logs for one service
- Count occurrences in a log: grep -c is not the answer
CliAI turns "what time was 1787043600" into the right flag for the machine you're on, and shows it before running. Install it in one line.