Linux Time Converter: Unix date Command Guide

When to use the shell instead of the browser converter

Use the shell when the timestamp is already inside a terminal, log pipeline, CI job, cron script, Docker container, SSH session, or incident-response notebook. In those situations, date gives you the answer without context switching.

Use the browser tools when you need visual timezone checking, automatic seconds-vs-milliseconds detection, or a quick sanity check before copying a value into production code. The Epoch to Time Converter is better for inspecting unknown integers, while the Date to Epoch Converter is better when you start with a wall-clock date.

What Linux time means

Linux time is Unix time

Linux time, Unix time, epoch time, and POSIX time usually mean the same numeric timestamp: seconds since 1970-01-01 00:00:00 UTC. The date command reads and prints that value through the operating system clock. Timezone only affects display; the underlying epoch integer stays the same.

Current Linux time vs human-readable time

date +%s prints the current Unix timestamp as a 10-digit seconds value. A normal date call prints a human-readable wall-clock date in the current timezone. Both values describe the same instant, but one is optimized for scripts and storage while the other is optimized for humans.

Year 2038 and 32-bit systems

Modern 64-bit Linux systems are safe for practical timestamp ranges, but old 32-bit signed time_t values overflow at 2147483647, which is 2038-01-19 03:14:07 UTC. If you are debugging embedded Linux, old databases, or legacy C code, check the Year 2038 problem guide before assuming every future date can be represented.

Copy-paste Linux date command examples

Get the current Linux timestamp

# Current Unix timestamp in seconds
date +%s

# Current Unix timestamp in milliseconds (GNU date)
date +%s%3N

# Current UTC datetime in ISO 8601 form
date -u +'%Y-%m-%dT%H:%M:%SZ'

In shell scripts, name the variable with the unit. created_at_seconds and created_at_ms are boring names, but they prevent the classic 1000x mistake when the value crosses into JavaScript, Java, or an analytics API.

Convert epoch seconds to a readable date

# GNU date on Linux: epoch seconds to UTC date
date -u -d @1700000000

# GNU date on Linux: epoch seconds to ISO 8601 UTC
date -u -d @1700000000 +'%Y-%m-%dT%H:%M:%SZ'

# Render the same instant in New York
TZ=America/New_York date -d @1700000000 +'%Y-%m-%d %H:%M:%S %Z'

The leading @ tells GNU date that the value is Unix epoch seconds. The -u flag forces UTC output. Without -u, the command uses the current process timezone, which can differ between a laptop, a server, and a CI container.

Convert a date string to epoch seconds

# GNU date on Linux: UTC datetime to Unix seconds
date -u -d '2023-11-14 22:13:20 UTC' +%s

# GNU date on Linux: ISO 8601 string to Unix seconds
date -u -d '2023-11-14T22:13:20Z' +%s

# Interpret the input as Los Angeles time
TZ=America/Los_Angeles date -d '2023-11-14 14:13:20' +%s

The output format +%s is the key part: it prints seconds since the Unix epoch. If you omit UTC or an explicit TZ=..., the command interprets the input in the machine's local timezone.

Convert epoch milliseconds in shell

# 13-digit milliseconds to seconds
echo $((1700000000000 / 1000))

# Convert epoch milliseconds to UTC date with awk
date -u -d @$(awk 'BEGIN { print 1700000000000 / 1000 }')

# Convert epoch milliseconds to ISO UTC with bc
date -u -d @$(echo '1700000000000 / 1000' | bc -l) +'%Y-%m-%dT%H:%M:%S.%3NZ'

This is the most common Linux timestamp converter bug: a 13-digit millisecond value looks like a valid number, but date -d @... reads it as seconds. The resulting date jumps far into the future. Divide by 1000 first.

macOS date command equivalents

# macOS / BSD: epoch seconds to UTC date
date -u -r 1700000000

# macOS / BSD: epoch seconds to ISO 8601 UTC
date -u -r 1700000000 +'%Y-%m-%dT%H:%M:%SZ'

# macOS / BSD: parse a UTC date string into Unix seconds
date -j -u -f '%Y-%m-%d %H:%M:%S %Z' '2023-11-14 22:13:20 UTC' +%s

If you install GNU coreutils on macOS, the GNU command is usually named gdate. In that setup, gdate -u -d @1700000000 behaves like Linux GNU date, while the system date remains BSD-style.

Edge cases that break timestamp shell commands

1. The server timezone is not what you think

date -d '2023-11-14 22:13:20' +%s depends on the process timezone. That might be UTC in a container, America/Los_Angeles on a laptop, or a regional timezone on an old server. For repeatable scripts, use either -u or TZ=Region/City.

2. DST transitions create repeated or missing local times

Local time is not a simple offset. Around daylight saving changes, one wall-clock hour can repeat or disappear. If you are converting timestamps for logs, API payloads, or database boundaries, convert in UTC first and format local time only for display.

3. %N is GNU-specific

GNU date supports nanosecond formatting with %N, which makes date +%s%3N useful for current epoch milliseconds. BSD date on macOS does not provide the same %N behavior, so use Python, Perl, Node, or gdate when you need portable millisecond output.

4. Negative timestamps may be tool-dependent

Dates before 1970 are valid Unix timestamps, but shell behavior can vary by platform, libc, and date implementation. If you are handling historical dates, verify the result with a language runtime such as Python's datetime or with the browser Epoch to Time Converter.

5. CI images may not have GNU coreutils extras

Slim containers sometimes include BusyBox date, which supports a smaller flag set than GNU date. Before putting timestamp conversion into a CI script, test the exact container image. A script that works on Ubuntu may fail on Alpine if it assumes GNU-only parsing.

Practical script patterns

Log with both ISO time and Unix seconds

now_s=$(date +%s)
now_iso=$(date -u +'%Y-%m-%dT%H:%M:%SZ')
printf 'time=%s epoch=%s event=%s\n' "$now_iso" "$now_s" "job_started"

This pattern gives humans a readable UTC datetime and gives machines a sortable numeric epoch. It is especially useful in cron logs and deployment scripts.

Build a half-open UTC date range

start=$(date -u -d '2026-07-01 00:00:00 UTC' +%s)
end=$(date -u -d '2026-08-01 00:00:00 UTC' +%s)

echo "created_at >= $start AND created_at < $end"

Use half-open ranges for logs and analytics windows: start <= value < end. It avoids double-counting events exactly on the boundary.

Convert a timestamp from a log line

ts=1700000000
date -u -d @"$ts" +'%Y-%m-%dT%H:%M:%SZ'

Quoting the variable is harmless here and keeps the habit consistent when your shell scripts later handle values with spaces or optional input.

Official references

For the exact behavior of your platform, check the manual for the implementation you are running:

• Linux man-pages: date(1)
• GNU Coreutils manual: date invocation
• The Open Group: strftime format directives
• FreeBSD date(1), close to macOS BSD date behavior

Related timestamp tools

For visual checking, cross-link this shell workflow with the rest of the site:

• Use the Epoch to Time Converter when you already have a Unix timestamp and want a readable date.
• Use the Date to Epoch Converter when you have a wall-clock date and need Unix seconds or milliseconds.
• Use the Unix Timestamp Reference for copyable current day, week, month, and year boundary timestamps.
• Use the Unix Timestamp Formats guide when you need to identify seconds, milliseconds, microseconds, or nanoseconds.