Unix Timestamp Converter

Convert a Unix epoch value — seconds, milliseconds, microseconds or nanoseconds — to a date in UTC and any IANA time zone, and back, with every machine format ready to paste.

Timestamp to date Date to timestamp

Unix timestamp

Seconds, milliseconds, microseconds or nanoseconds — detected automatically.

Interpret as

Time zone

Convert several at once

One value per line

Unix timestamps or ISO 8601 dates, one per line. The first 20 are converted.

UTC

Tuesday, November 14, 2023 at 10:13:20 PM

1700000000 seconds

UTC

Tuesday, November 14, 2023 at 10:13:20 PM

GMT+00:00 · UTC

ISO 8601 · RFC 3339

2023-11-14T22:13:20Z

2023-11-14T22:13:20+00:00

seconds 1700000000 millis 1700000000000 micros 1700000000000000 nanos 1700000000000000000 isoUtc 2023-11-14T22:13:20Z isoOffset 2023-11-14T22:13:20+00:00 rfc5322 Tue, 14 Nov 2023 22:13:20 +0000 httpDate Tue, 14 Nov 2023 22:13:20 GMT sql 2023-11-14 22:13:20 sheet 45244.925925926 hex 0x6553F100 isoWeek 2023-W46-2 · day 318

Copy-ready formats

Format	Value
Unix seconds	1700000000
Milliseconds	1700000000000
Microseconds	1700000000000000
Nanoseconds	1700000000000000000
ISO 8601 · UTC	2023-11-14T22:13:20Z
ISO 8601 · UTC	2023-11-14T22:13:20+00:00
RFC 5322 (email)	Tue, 14 Nov 2023 22:13:20 +0000
HTTP-date (RFC 9110)	Tue, 14 Nov 2023 22:13:20 GMT
SQL DATETIME (UTC)	2023-11-14 22:13:20
Spreadsheet serial	45244.925925926
Hexadecimal seconds	0x6553F100
ISO week date · ordinal day	2023-W46-2 · day 318

Do it in code

Code snippet language

Python

Snippet

Converts the timestamp above, in the zone above.

from datetime import datetime, timezone
from zoneinfo import ZoneInfo

d = datetime.fromtimestamp(1700000000, tz=timezone.utc)
print(d.isoformat())
print(d.astimezone(ZoneInfo("UTC")))

Batch results

The last column is UTC.

Input	Read as	UTC	Selected zone

Reference

Value	What it is
0	1970-01-01T00:00:00Z · the Unix epoch
-1	1969-12-31T23:59:59Z · one second before the epoch
1000000000	2001-09-09T01:46:40Z · the first billion seconds
1234567890	2009-02-13T23:31:30Z · the digits 1234567890
1500000000	2017-07-14T02:40:00Z
1700000000	2023-11-14T22:13:20Z · this page's default
2000000000	2033-05-18T03:33:20Z · two billion seconds
2147483647	2038-01-19T03:14:07Z · the largest signed 32-bit timestamp
60	one minute
3600	one hour
86400	one day
604800	one week
2629746	one Gregorian mean month — 365.2425 / 12 days
31556952	one Gregorian mean year — 365.2425 days

Unix time has no leap seconds — every day is exactly 86,400 seconds, and a time field will not accept :60.

Convert a duration in seconds into days, weeks or years

Updated: September 14, 2026

Unix timestamp converter. Epoch value to a date in UTC and a named time zone, and back.

A Unix timestamp converter reads an epoch value in seconds, milliseconds, microseconds or nanoseconds and shows that instant in UTC and in a named time zone. It runs the other way too, turning a date and a wall-clock time in a chosen zone back into a timestamp, and it tells you when the hour you typed is one that daylight saving skipped or ran twice.

What Is a Unix Timestamp?

A Unix timestamp is the number of seconds elapsed since 1970-01-01T00:00:00Z, counted without leap seconds. IEEE Std 1003.1 (POSIX) §4.16 defines the value so that every day holds exactly 86,400 seconds, which is why two timestamps can be subtracted into a duration without consulting a calendar, and why the reference table at the foot of this page ends with the reminder that a time field will not accept :60.

That number names an instant: one moment, the same for everyone who lived through it. A wall clock names something else — a reading on a dial, which depends on which zone the dial sits in and on the rules that zone had on that date. The timestamp carries no zone at all, which is why the same value can be shown as a UTC date and as a local date side by side without either being wrong.

Going from an instant to a wall clock is safe: a zone plus an instant always produce one reading. The reverse is where systems go wrong, because twice a year a named zone loses an hour or repeats one, so a date plus a time can name no instant at all, or two of them. On 2023-03-12 in America/New_York the clocks went from 02:00 straight to 03:00, so 02:30:00 never happened there. On 2023-11-05 in the same zone, 01:30:00 happened twice — once at 1699162200 and again at 1699165800, an hour apart.

A converter has to answer anyway, and answering without saying which of the two it chose is how an hour goes missing from a booking or a billing window. Tom Lane raised the same objection on the PostgreSQL mailing list in March 2010, arguing the database should throw an error rather than keep "silently doing something that's got a 50-50 chance of being wrong". This page takes the visible route: it converts, then names what it did. For the hour that does not exist it prints the reading it used instead; for the hour that happens twice it shows the earlier timestamp and prints the later one beside it.

Reading the number at all is the other half of the job. The same instant is 1700000000 in seconds, 1700000000000 in milliseconds, 1700000000000000 in microseconds and 1700000000000000000 in nanoseconds, so the digit count is the tell — ten digits for seconds today, thirteen for milliseconds, sixteen for microseconds, nineteen for nanoseconds. JavaScript and Java hand you milliseconds, most Unix tooling and most SQL columns hand you seconds, PostgreSQL stores to the microsecond, and a tracing payload can go finer still. This page reads the magnitude, reports which unit it settled on, and lets the Interpret as picker override it when a short value is a finer unit than it looks.

Everything else on the page comes from that one integer: the UTC date, the date in the zone you picked, the ISO 8601 string, and a table of copy-ready renderings covering SQL, HTTP headers, email dates, spreadsheet serials, hexadecimal and the ISO week date.

How to Use This Timestamp Converter

The page opens on Timestamp to date with 1700000000 already in the field, so a finished conversion is on screen before you type anything. Switch the direction and the form starts on 2023-11-14 at 22:13:20, which in UTC converts back to 1700000000 — the two starting states are each other's inverse, by design.

1. Set the direction. Timestamp to date takes a number and returns dates; Date to timestamp takes a date and a time read in the zone you chose and returns the number. The fields swap when you switch, and the three result cards stay in the same three places.

2. Paste your value into Unix timestamp. Surrounding quotes, grouping commas and a trailing L from a Java long literal are stripped before parsing, and a hexadecimal value such as 0x6553F100 is read as 1700000000. Anything the parser cannot use answers: Not a timestamp. Strip quotes, commas and letters, or use 0x… for hexadecimal.

3. Leave Interpret as on Auto-detect unless it guesses wrong. Detection works on magnitude, so a thirteen-digit value is read as milliseconds and a nineteen-digit value as nanoseconds. Pin Seconds, Milliseconds, Microseconds or Nanoseconds by hand for a short value whose unit the magnitude cannot reveal.

4. Choose a Time zone. It starts on Your device time zone, and the list holds UTC plus a shortlist of named ids grouped under Americas, Europe & Africa, Asia and Oceania. Those ids are printed the way the IANA database spells them — America/New_York, not New York — because that exact string is what you paste into code.

5. Read the three cards. Converting to a date, the first is the UTC reading with the value and its unit written out underneath it, the second is the same instant in your chosen zone with its offset, and the third is ISO 8601 · RFC 3339 with the offset form below it. Converting to a timestamp, the first card becomes Unix timestamp (seconds) and the second becomes Milliseconds. Each card has its own copy button, and the button copies the string the card is showing.

6. Press Use current time to load the present moment into whichever direction you are in.

At the foot of the form sits a folded block, Convert several at once, which takes one value per line and handles the first twenty. It accepts Unix timestamps and ISO 8601 dates, and it appears only in the Timestamp to date direction.

Between the cards and the tables run a few short lines: how long ago or how far ahead the instant falls, the current Unix time as of when the page loaded, a note naming the unit used and what the input was normalized to, and — for a nine-digit value in the band where one is usually missing — the hint that the timestamp looks a digit short.

Below those, Copy-ready formats lists twelve renderings of the same instant. The amber Check this box appears only when the value has something worth knowing about it: a skipped or doubled hour, a value past the signed 32-bit ceiling, a date before 1970 or before 1582-10-15, a value outside the representable range, or a zone sitting on daylight saving time at that instant. Do it in code opens a snippet in Python, JavaScript, SQL, Bash, PHP or Go, wired to the value and zone above it. Batch results prints the table your pasted lines produced, and Reference, folded shut at the bottom, holds the landmark values worth knowing on sight.

Worked Conversions

Reading 1700000000 out of a log line

Leave the direction on Timestamp to date, paste 1700000000 into Unix timestamp, keep Interpret as on Auto-detect and set Time zone to UTC. The first card reads Tuesday, November 14, 2023 at 10:13:20 PM, with 1700000000 seconds written underneath — the unit is named in full, so there is no guessing about what the detector settled on. The third card gives 2023-11-14T22:13:20Z, and beneath it the offset form 2023-11-14T22:13:20+00:00. No warning box appears, because there is nothing unusual about this value.

The same instant in all twelve copy-ready formats

A prose date answers the question, but what goes back into the query, the header or the spreadsheet cell is a string in a specific format. All twelve rows below describe the one instant 1700000000.

Format	Value for 1700000000
Unix seconds	1700000000
Milliseconds	1700000000000
Microseconds	1700000000000000
Nanoseconds	1700000000000000000
ISO 8601 · UTC	2023-11-14T22:13:20Z
ISO 8601 · selected zone	2023-11-14T22:13:20+00:00
RFC 5322 (email)	Tue, 14 Nov 2023 22:13:20 +0000
HTTP-date (RFC 9110)	Tue, 14 Nov 2023 22:13:20 GMT
SQL DATETIME (UTC)	2023-11-14 22:13:20
Spreadsheet serial	45244.925925926
Hexadecimal seconds	0x6553F100
ISO week date · ordinal day	2023-W46-2 · day 318

The sixth row is headed with whichever zone is selected, so with UTC chosen it restates the fifth row in offset form; pick America/New_York and it becomes the local ISO string instead. The email and HTTP rows keep their English weekday and month abbreviations whatever your locale, because RFC 5322 and RFC 9110 fix those spellings in the grammar.

A milliseconds value read in New York

Paste 1700000000123 and set Time zone to America/New_York. Auto-detect reads thirteen digits as milliseconds, and the subtitle under the first card says 1700000000123 milliseconds. The UTC card still reads Tuesday, November 14, 2023 at 10:13:20 PM; the zone card reads Tuesday, November 14, 2023 at 5:13:20 PM, five hours behind UTC that day, and the offset row of the formats table becomes 2023-11-14T17:13:20-05:00. The milliseconds are still carried through the conversion — they do not show in a display cut to the second.

An hour that never happened

Switch to Date to timestamp, set Date to 2023-03-12, Time to 02:30:00 and Time zone to America/New_York. That reading never existed: the clocks in New York went from 02:00 straight to 03:00 that morning. The page converts anyway and says what it did. The first card gives 1678602600, the ISO card gives 2023-03-12T06:30:00Z with 2023-03-12T01:30:00-05:00 beneath it, and the amber Check this box reads: 2023-03-12 02:30:00 does not exist in America/New_York — the clocks jumped forward. Showing Mar 12, 2023, 1:30:00 AM instead.

This is the failure mode to watch for in a scheduler. A row stored as 02:30 local on a spring-forward date will fire at an hour the calendar does not contain, and resolutions differ: PostgreSQL and Java step forward an hour to 03:30, the C++ standard library raises a nonexistent-local-time exception, and this page steps back to 01:30 and prints the fact. Which answer you were handed is the difference between a reminder an hour early and one an hour late.

An hour that happens twice

Keep Date to timestamp and America/New_York, set Date to 2023-11-05 and Time to 01:30:00. Here the zone repeats an hour rather than losing one: the clocks fell back from 02:00 to 01:00, so 01:30 came round a second time. The first card gives 1699162200, and the Check this box names the other candidate: 2023-11-05 01:30:00 happens twice in America/New_York. Showing the first, 1699162200; the second is 1699165800. A second warning line joins it, because that first instant is still on daylight saving time.

The two candidates sit 3,600 seconds apart. Which one you want depends on the question being asked: the first is the last 1:30 of daylight saving time, the second is the first 1:30 of standard time. A shift that clocked in at 01:00 and out at 02:00 on that date lasted two hours, not one, and a system that picked the wrong candidate will bill for one.

Nanoseconds from a trace, read in Tokyo

Paste 1700000000123456789, leave Interpret as on Auto-detect and set Time zone to Asia/Tokyo. Nineteen digits are read as nanoseconds, and the value survives intact: the nanoseconds row still reads 1700000000123456789 and the microseconds row 1700000000123456, with no digits rounded away at the edge of a floating-point number. The zone card reads Wednesday, November 15, 2023 at 7:13:20 AM, Tokyo being nine hours ahead of UTC, which is the following calendar day there for an instant that is still November 14 in UTC — the ordinary reason a daily report in one region disagrees with a daily report in another.

The last second a 32-bit clock can hold

Paste 2147483647 with the zone on UTC. It converts to 2038-01-19T03:14:07Z, and the hexadecimal row reads 0x7FFFFFFF, every bit below the sign bit set. No warning fires at this value, because the value still fits; one second more and the Check this box appears with: Outside the signed 32-bit range — a system storing this in an int32 cannot hold it. The limit is 2147483647 = 2038-01-19T03:14:07Z.

That ceiling is the Year 2038 problem in a single line. A signed 32-bit counter incremented past 2147483647 wraps to a negative number and starts reporting December 1901. The wrapped value still looks like a date, so comparisons and expiry checks carry on running against one that is 137 years wrong, and nothing throws to tell you.

Mistakes That Cost an Hour (or 137 Years)

Feeding milliseconds into a seconds parser — a thirteen-digit value handed to something expecting seconds lands tens of thousands of years in the future, and the same error reversed drops you into January 1970. When the date that comes back is absurd, the unit was misread, and the direction of the absurdity says which way: too far ahead means milliseconds went into a seconds function.
Converting a local date with whatever zone the machine happens to be in — identical input gives a different timestamp on a laptop in Madrid and on a CI runner set to UTC. Pick the zone yourself; that is what the Time zone control is for, and it is why the ids are spelled the way the IANA database spells them.
Assuming every wall-clock hour exists — 02:30 on a spring-forward morning and 01:30 on a fall-back morning are the two readings that break schedulers and billing windows. Store instants wherever you can, and when a local reading has to be accepted, decide in advance which of the two candidates you mean.
Putting an epoch value in a signed 32-bit column — the column tops out at 2147483647, which is 2038-01-19T03:14:07Z. A value past it does not raise an error, it wraps negative and reads as December 1901, which is far harder to notice than a crash.
Expecting leap seconds to be in the count — they are not. Unix time treats every day as exactly 86,400 seconds, so there is no room for a 61st second and a time field will not accept :60. A duration obtained by subtracting two timestamps is a count of non-leap seconds, which is not the same as the seconds an atomic clock ticked off across one.
Assuming a negative timestamp travels — dates before 1970 convert here as ordinary values, and the page flags them with: Negative — this instant is before 1970-01-01. Some languages and databases reject negative timestamps. A signed 32-bit counter reaches no further back than 13 December 1901 at 20:45:52 UTC, so test the receiving system before storing a birth date as an epoch value.

The Arithmetic Behind the Conversion

t_s = \left\lfloor \frac{v \cdot s_u}{10^{9}} \right\rfloor \qquad \text{wall clock} = \text{UTC}(t_s) + \text{offset}(t_s, z)

$v$ = The value you typed, once quotes, grouping commas and a trailing Java long suffix have been stripped. A leading 0x reads it as hexadecimal.
$s_u$ = Nanoseconds per unit: 1,000,000,000 for seconds, 1,000,000 for milliseconds, 1,000 for microseconds and 1 for nanoseconds.
$t_s$ = Unix seconds. The division floors toward the past instead of truncating toward zero, which is what keeps a value from before 1970 on the correct side of the epoch.
$z$ = The IANA zone id you picked, such as America/New_York or Asia/Tokyo.
$\text{offset}(t_s, z)$ = How far ahead of UTC that zone is at that instant, from the IANA Time Zone Database. It takes the instant as an argument because it changes at every daylight saving transition.

The unit handling is one scaling and one floor:

t_s = \left\lfloor \frac{v \cdot s_u}{10^{9}} \right\rfloor

The typed value is scaled to nanoseconds, then floored to whole seconds for display. Carrying nanoseconds throughout is what keeps a nineteen-digit value intact: 1700000000123456789 comes back with all nineteen digits, and its microsecond form 1700000000123456, rather than losing its tail at the precision limit of a floating-point number.

The reverse direction inverts the wall-clock relation rather than the scaling one, and that inversion is not a function. Solving for the instant behind a typed date and time means asking which candidate instants land on exactly the wall clock you wrote. In an ordinary hour there is one. In an hour a zone skips there is none, and the page reports the reading it used in its place. In an hour a zone repeats there are two, and the page shows the earlier and names the later.

Two of the twelve copy-ready formats deserve spelling out, because they count from a different origin. The spreadsheet serial uses the day scale Excel and Google Sheets share, on which the Unix epoch falls at day 25569:

\text{serial} = \frac{t_s}{86400} + 25569

For 1700000000 that gives 45244.925925926 — paste it into a cell, format the cell as a date, and the same instant is in your sheet. The hexadecimal row is the number in base 16: 1700000000 is 0x6553F100, and the signed 32-bit ceiling 2147483647 is 0x7FFFFFFF, which is the quickest way to see why that value in particular is a ceiling.

Digit Count to Unit, at a Glance

Digits	What Auto-detect reads it as	The same instant
10	Seconds	1700000000
13	Milliseconds	1700000000000
16	Microseconds	1700000000000000
19	Nanoseconds	1700000000000000000
9, from 100000000 to 179999999	Seconds, with a hint that a digit may be missing	170000000
Any, prefixed 0x	Hexadecimal, then by magnitude	0x6553F100

What This Converter Does Not Do

The zone picker is a shortlist, not the whole IANA database. It carries UTC, your device zone and a set of named ids grouped under Americas, Europe & Africa, Asia and Oceania, chosen to cover the zones that turn up in most logs and most teams. Offsets and transitions come from the same database either way, so what a missing id costs you is the convenience of selecting it here.

The batch box takes twenty lines and returns a table on screen. It reads Unix timestamps and ISO 8601 dates and nothing else, so a line reading next friday or 14/11/2023 comes back marked not a timestamp. There is no file upload and no CSV export, which makes a few thousand rows out of a data export a job for a script — the Do it in code fold hands you a starting point in Python, JavaScript, SQL, Bash, PHP or Go.

Only the Unix family converts here. LDAP and Windows FILETIME values, .NET ticks, Apple Cocoa and HFS+ dates, Snowflake ids, GPS time and NTP timestamps each count from their own epoch in their own unit, and none of them are recognized on this page.

Nor does it turn one zone into another, count down to a date, or express a duration in seconds as days and weeks. That last one is the time converter, linked at the foot of the page; the gap between two calendar dates belongs to the date duration calculator.

Two limits are properties of the representation rather than of the page. Nothing outside ±8,640,000,000,000 seconds from the epoch can be represented at all, and a date before 1582-10-15 is shown on the proleptic Gregorian calendar — the arithmetic extended backwards past the point where that calendar was adopted, so the date will not match what a contemporary record wrote down. Both cases raise a line in the Check this box instead of failing without comment.

There is also no ticking clock here. The page is static, so the relative line and the epoch note are both measured from the moment the page loaded and say as much; Use current time pulls in the present moment on demand.

Terms Worth Pinning Down

Unix time (epoch time)

The number of seconds elapsed since 1970-01-01T00:00:00Z, counted with every day treated as exactly 86,400 seconds. Defined in IEEE Std 1003.1 (POSIX) §4.16.

Instant

A single point on the timeline, identical for every observer. A Unix timestamp names an instant and carries no time zone of its own.

Wall clock

A date and time as a clock would show it, such as 2023-11-05 at 01:30:00. It only names an instant once you also say which zone the clock is in — and on two mornings a year, not even then.

UTC offset

How far ahead of or behind UTC a zone runs at a given instant, written +09:00 or -05:00. It belongs to the instant as much as to the zone, because it changes at every daylight saving transition.

IANA time zone id

The canonical name of a zone in the IANA Time Zone Database, written Area/Location: America/New_York, Europe/Madrid, Asia/Tokyo. The id is the same string in every language, which is why this page prints it untranslated.

Daylight saving gap

The hour a zone loses when its clocks move forward. Wall-clock readings inside it name no instant at all — 02:30 on 2023-03-12 in America/New_York is one of them.

Daylight saving overlap

The hour a zone repeats when its clocks move back. Wall-clock readings inside it name two instants an hour apart, such as 1699162200 and 1699165800 for 01:30 on 2023-11-05 in America/New_York.

Leap second

An extra second inserted into UTC to keep it in step with the Earth's rotation. Unix time does not count them, which is why a Unix day is always 86,400 seconds and a time field will not accept :60.

Signed 32-bit range

What a 32-bit signed integer can hold, from -2147483648 to 2147483647. As epoch seconds that runs from 13 December 1901 at 20:45:52 UTC to 2038-01-19T03:14:07Z.

Spreadsheet serial

The day count Excel and Google Sheets keep internally, on which the Unix epoch is day 25569. Dividing epoch seconds by 86,400 and adding 25569 turns a timestamp into a number a sheet will display as a date.

Unix Timestamp Conversion — Frequently Asked Questions

How do I convert a Unix timestamp to a date?

Paste the number into the Unix timestamp field and pick a time zone. The page returns the UTC date, the date in that zone and the ISO 8601 string, and works out on its own whether the value is in seconds, milliseconds, microseconds or nanoseconds.

Is my timestamp in seconds or milliseconds?

Count the digits. Ten is seconds today, thirteen is milliseconds, sixteen is microseconds, nineteen is nanoseconds. A date that lands in 1970 means seconds were read as a finer unit; a date tens of thousands of years ahead means the opposite.

Why does the same timestamp show two different times?

Because a timestamp names an instant, not a clock reading. Paste 1700000000123 with America/New_York selected and the ISO offset row reads 2023-11-14T17:13:20-05:00, while the UTC card for the same instant reads Tuesday, November 14, 2023 at 10:13:20 PM. Neither is more correct than the other; the difference is the zone's offset at that instant, which is why the page shows UTC and your chosen zone together rather than picking one for you.

What happens if the local time I enter does not exist?

You get a timestamp and a warning. Choose Date to timestamp, 2023-03-12 at 02:30:00 in America/New_York, and the answer is 1678602600 with this note: 2023-03-12 02:30:00 does not exist in America/New_York — the clocks jumped forward. Showing Mar 12, 2023, 1:30:00 AM instead. New York's clocks went from 02:00 to 03:00 that morning, so nothing in the skipped hour is a real moment. Systems resolve it differently — PostgreSQL and Java step forward to 03:30, the C++ standard library raises an exception — so the valuable part is knowing which answer you were handed.

Which timestamp do I get when 1:30 AM happens twice?

The earlier one, with the later one printed beside it. On 2023-11-05 in America/New_York, 01:30:00 is 1699162200 the first time round and 1699165800 the second, 3,600 seconds apart. The first is the last 1:30 of daylight saving time, the second the first 1:30 of standard time. Tom Lane argued on the PostgreSQL mailing list in March 2010 that resolving this silently amounts to "doing something that's got a 50-50 chance of being wrong" — this page resolves it and then shows its work.

How do I convert a Unix timestamp in Excel or Google Sheets?

Divide by 86,400 and add 25569, then format the cell as a date: =A1/86400+25569. The 25569 is where the Unix epoch falls on the spreadsheet day-count scale. The Spreadsheet serial row of the copy-ready formats table has already done the arithmetic — for 1700000000 it reads 45244.925925926, which pastes straight into a cell.

What is the year 2038 problem?

A signed 32-bit integer stops at 2147483647, which as epoch seconds is 2038-01-19T03:14:07Z. One second later the counter wraps negative and the date reads December 1901, which is a plausible-looking date rather than an error, so the failure is silent. Certificates, session expiry, scheduling and anything that sorts by time are the usual casualties. Paste any value above 2147483647 here and the Check this box names the limit.

Can a Unix timestamp be negative?

Yes. A negative value counts seconds backwards from the epoch, so -1 converts to 1969-12-31T23:59:59Z. This page handles them and raises a note: Negative — this instant is before 1970-01-01. Some languages and databases reject negative timestamps. A signed 32-bit counter bottoms out at 13 December 1901 at 20:45:52 UTC, so a birth date stored as an epoch value is worth testing against whatever will read it.

Should I store a Unix timestamp or an ISO 8601 string?

Store whichever your database indexes natively, and be explicit about the zone either way. An integer compares and sorts as a number and carries no zone, which is what makes it safe in storage; an ISO 8601 string with an offset is readable by a person and unambiguous in an API payload. The usual arrangement is to keep the instant and render ISO 8601 at the edges, which is why this page returns both from one input.

Does this converter handle leap seconds?

No, and neither does Unix time. Every Unix day is exactly 86,400 seconds by definition, so no timestamp exists for a leap second and the time field will not accept :60. A duration you get by subtracting two timestamps is a count of non-leap seconds.

Can I convert several timestamps at once?

Yes, twenty at a time. Open Convert several at once under the form and put one value per line; Batch results then returns each input, the unit it was read as, the UTC date and the date in your selected zone. It takes Unix timestamps and ISO 8601 dates, and anything else comes back marked not a timestamp. There is no file upload or CSV export, so a larger export belongs in a script — the Do it in code fold gives you one to start from.

Is this timestamp converter free, and does my data leave the browser?

It is free to use and needs no account. The page is static and the conversion runs in your browser, so a timestamp pasted out of a production log is not uploaded anywhere to be converted. The same tool is available as an embeddable widget if you want it sitting on an internal runbook or a docs page.

How accurate is the result?

The instant arithmetic is exact to the nanosecond: a nineteen-digit value comes back with all nineteen digits. Offsets and daylight saving transitions are read from the IANA Time Zone Database, so a historical date is resolved with the rules recorded for that date rather than today's. The two cases with no single right answer — a wall clock its zone skipped, and one its zone repeated — are the two the page names instead of guessing.

Sources & References

Content verified by the Smart Calculators Team