Epoch Converter: Unix Timestamp to Date

Paste any timestamp or date and get it in words, in your time zone and in UTC, with everything else the number could be.

s · ms · µs · ns · FILETIME · .NET · Excel · NTP · GPS · runs in your browser

Example · 817876800

Saturday

December 2, 1995

04:00:00 UTC

UTC
Sat, Dec 2, 1995 · 04:00:00
Sat, Dec 2, 1995 · 04:00:00UTC · UTC+00:00
Relative
31 years ago
Written as
ISO 8601 · UTC
1995-12-02T04:00:00Z
ISO 8601 · UTC
1995-12-02T04:00:00Z
RFC 5322 · emailthe format RFC 2822 defined
Sat, 02 Dec 1995 04:00:00 +0000
HTTP dateRFC 9110
Sat, 02 Dec 1995 04:00:00 GMT
SQL DATETIMEUTC
1995-12-02 04:00:00
Seconds
817876800
Milliseconds
817876800000
Microseconds
817876800000000
Nanoseconds
817876800000000000

One number · every epoch

7 readings land on a real date

Read as Unix seconds by its length: 9 digits. As GPS seconds it would be December 6, 2005: a real date too, so it stays one click away.

ReadingLands on
1900–2100: a real dateToday2038: the 32-bit limitLands on no real datePick a reading to use it
Now

Milliseconds
Microseconds
Nanoseconds
ISO 8601

Your browser's clock counts whole milliseconds: the zeros after them are padding, not precision.

Date and time → timestamp
Time zone

UTC · UTC+00:00 on this date

1793813880
Milliseconds
1793813880000
ISO 8601
2026-11-04T17:38:00Z
Start and end in UTC
StartEnd
Day17937504001793836799
Month17934912001796083199
Year17672256001798761599

Everything happens in this tab: nothing you paste is sent anywhere.

How to use this epoch and Unix timestamp converter

Paste the timestamp you have into the field, in whatever unit it is in, and the date appears in your own time zone and in UTC. You can also type a date, an email's Date header or the word now to get its epoch time.

As a Unix time converter it works both ways. It reads a number in seconds, milliseconds, microseconds and nanoseconds at once, picks the reading that lands on a real date, says why, and keeps the other readings one click away. Below the answer, the same digits are read as a Windows, .NET, Mac, Excel, NTP and GPS timestamp, and every format can be copied.

Epoch converter reading 133756272000000000 as a Windows FILETIME: November 9, 2024, with every epoch on one time lineEpoch converter reading 133756272000000000 as a Windows FILETIME: November 9, 2024, with every epoch on one time linePaste anythingA number in any unit, an ISO date, an email's Date header, a SQL datetime or the word now. The pill says how it was read.The digits, countedThe ruler under the number groups its digits in threes, so 18 digits read as six groups: the first clue to what it is.The answer firstThe weekday and the date in words, then the time in UTC and in your own time zone, and every format to copy.Which reading, and whyThe page says in words which reading it chose and why, and names the other reading that also lands on a real date.Every other epochThe same digits read as every unit and every epoch, each a bar from its own start. Pick a row to use that reading.
The tool reading a Windows FILETIME. Select a number to see what each part does.

What is epoch time, and why does it start in 1970?

Epoch time, or Unix time, is the number of seconds since 1970-01-01 00:00:00 UTC, the moment POSIX calls the Epoch. The timestamp 0 is that moment, and 817876800 is 1995-12-02 04:00 UTC.

No primary source records why 1970 was chosen. The first Unix manual, in November 1971, counted sixtieths of a second from 1 January 1971 and noted that its clock would run out in about two and a half years; by the Seventh Edition in 1979 the count was seconds since 1 January 1970, a round date close to when Unix was being written. UTC itself only began in 1972, so earlier timestamps are UTC by convention.

First Edition Unix, 1971sixtieths of a second since January 1, 1971, in 32 bits

full on April 8, 1973 · 2.27 years

Seventh Edition Unix, 1979seconds since January 1, 1970, in a signed 32-bit number

1901-12-13 → 2038-01-1968 years each way

negative counts: before 1970

The chronological--minded user will note that 2**32 sixtieths of a second is only about 2.5 years.

UNIX Programmer's Manual, First Edition, time (II), November 3, 1971

Every epoch this page reads, on one line

  1. .NET0001-01-01 · 100 ns ticks
  2. Windows FILETIME1601-01-01 · 100 ns ticks
  3. Excel1899-12-30 · days
  4. NTP1900-01-01 · seconds
  5. Mac HFS+1904-01-01 · seconds
  6. Excel 19041904-01-01 · days
  7. Unix1970-01-01 · seconds
  8. GPS1980-01-06 · seconds
Both bars are computed from the counter's size: 2³² sixtieths of a second fill 2.27 years, a little under the manual's own estimate. Every other epoch this page reads starts somewhere else on the same line, drawn on the converter's own time axis. Source: time (II), 1971, time (2), 1979

Is my timestamp in seconds, milliseconds, microseconds or nanoseconds?

Count the digits: a current timestamp has 10 digits in seconds, 13 in milliseconds, 16 in microseconds and 19 in nanoseconds. JavaScript and Java use milliseconds; Unix tools and most APIs use seconds.

The digit count is a strong hint, not proof. NTP, GPS and Mac timestamps are also ten digits today, and a Windows FILETIME and a .NET tick count are both eighteen, which is why this page reads every scale at once and shows the reading it chose next to the others. A FILETIME is also bigger than JavaScript can hold exactly, so the page keeps the digits as you pasted them.

10 digits · 4 scales · the digits alone don't say which

Unix seconds1792972800
NTP seconds4001961600
GPS seconds1477008018
Mac HFS+3875817600
Unix milliseconds1792972800000
Unix microseconds1792972800000000

18 digits · 2 scales · only the first digit tells them apart

Windows FILETIME134374464000000000
.NET ticks639285696000000000
Unix nanoseconds1792972800000000000

10 digits of seconds run from 2001-09-09T01:46:40Z to 2286-11-20T17:46:39Z. That is a span of 285 years, not a unit.

Every value is the same instant, October 26, 2026, 00:00 UTC, on its own scale. The length tells the Unix units apart; it can't tell the epochs apart. Source: ECMA-262 §21.4.1, [MS-DTYP] 2.3.3, DateTime.Ticks

How do I convert a Unix timestamp to a date in my time zone?

A Unix timestamp has no time zone: it names one instant everywhere. The date depends on where you read it, so the page shows your own zone and UTC side by side, and any other zone you pick.

The zone picker uses the IANA time zone database, the same one your operating system uses, so daylight saving changes are applied for the date itself, not for today. Going the other way, a date typed without an offset is read as UTC, and the page offers to read it in your own zone instead.

One instant1793057400= 2026-10-26T23:30:00Z

  • Los Angeles16:30Mon, Oct 26UTC−07:00
  • New York19:30Mon, Oct 26UTC−04:00
  • UTC23:30Mon, Oct 26UTC+00:00
  • Berlin00:30Tue, Oct 27UTC+01:00
  • Kolkata05:00Tue, Oct 27UTC+05:30
  • Tokyo08:30Tue, Oct 27UTC+09:00
  • Lord Howe10:30Tue, Oct 27UTC+11:00

Berlin, March 29, 202623 hours · the clocks jumped from 02:00 to 03:00

Berlin, October 25, 202625 hours · the clocks went back from 03:00 to 02:00

Central European Standard Time · UTC+01:00Central European Summer Time · UTC+02:00the hour that happened twicethe hour that never happened

One timestamp, 7 wall clocks: where the local date isn't UTC's, it is marked. On Berlin's two change days in 2026, one wall-clock time named no instant and another named two. Source: ECMA-262 §21.4.1.19, IANA tz

What happens to Unix time in 2038?

A Unix time stored as a signed 32-bit integer runs out at 2147483647, which is 2038-01-19 03:14:07 UTC; one second later it wraps to a date in December 1901. Systems that count in 64 bits, as POSIX now requires, are not affected.

The risk in 2026 is storage, not clocks: a MySQL TIMESTAMP column still ends at 2038-01-19 03:14:07 UTC, and so does any file format or embedded device that kept a 32-bit field. NTP has an earlier rollover of its own: its 32-bit seconds wrap in 2036. The page marks any timestamp near or past the 2038 boundary.

2,147,483,647the largest signed 32-bit number

01111111 11111111 11111111 11111111

Tue, Jan 19, 203803:14:07 UTC

+ 1 second

-2,147,483,648the same 32 bits, read as a signed number

10000000 00000000 00000000 00000000

Fri, Dec 13, 190120:45:52 UTC

Last second, UTC

Signed 32-bit time_t2038-01-19 03:14:07
Unsigned 32-bit seconds2106-02-07 06:28:15
MySQL TIMESTAMP column2038-01-19 03:14:07
NTP, era 02036-02-07 06:28:15
Mac HFS+ dates2040-02-06 06:28:15

today2038-01-19

Every end is computed from the field's own size: the last whole second it can hold. A 64-bit time_t, which POSIX.1-2024 requires, reaches about 292 billion years either side of 1970. Source: POSIX.1-2024 A.4.19, MySQL 8.4, RFC 5905 §6, TN1150

Can a Unix timestamp be negative?

Yes: a negative timestamp is a date before 1970. -1 is 1969-12-31 23:59:59 UTC, and -86400 is 1969-12-31 00:00:00 UTC.

POSIX itself leaves negative values undefined, but GNU and most systems treat them as dates before 1970 by documented extension, and so do JavaScript, Python and PostgreSQL. MySQL is the exception: its TIMESTAMP column starts in 1970, and FROM_UNIXTIME(-1) returns NULL. Birth dates and historical records are ordinary negative timestamps, so the page reads them as dates rather than calling them a mistake.

SecondsHow far back (log scale)Date, UTC

0Thu, Jan 1, 197000:00:00 UTC
-1Wed, Dec 31, 196923:59:59 UTC
-86,400Wed, Dec 31, 196900:00:00 UTC
-31,536,000Wed, Jan 1, 196900:00:00 UTC
-1,000,000,000Sun, Apr 24, 193822:13:20 UTC
-2,147,483,648Fri, Dec 13, 190120:45:52 UTC
  • POSIXIf the year is <1970 or the value is negative, the relationship is undefined.
  • GNU date@-1 is 1969-12-31 23:59:59 UTC: negative counts, as an extension to POSIX
  • JavaScriptany date within about 273,790 years of 1970, either way
  • MySQL TIMESTAMPstarts at 1970-01-01 00:00:01 UTC: it can't hold a negative value
Each value read as Unix seconds. The bars are on a log scale, so the small values stay visible. The last row is the smallest number a signed 32-bit field holds: the far edge of the 2038 problem. Source: POSIX.1-2024 §4.19, GNU Coreutils, ECMA-262 §21.4.1, MySQL 8.4

Windows, .NET, Mac, Excel, NTP and GPS: the other epochs

Many systems count from their own zero: Windows from 1601, .NET from the year 1, Mac and HFS+ from 1904, Excel from 1900, NTP from 1900 and GPS from 6 January 1980. A number that makes no sense as a Unix timestamp is often one of these.

The FILETIME 133756272000000000, for example, counts 100-nanosecond intervals since 1601 and is 2024-11-09 12:00:00 UTC. Excel counts days, and treats 1900 as a leap year on purpose, so its serials below 61 are a day off and the page flags them. GPS time skips leap seconds and has run 18 seconds ahead of UTC since 2017.

EpochCountsSinceOn Oct 26, 2026DigitsTime zoneWhere you meet it
Unix secondsseconds1970-01-01179297280010UTC (POSIX)date +%s, Python time.time()
Unix millisecondsmilliseconds1970-01-01179297280000013UTCJavaScript Date.now(), Java
Unix nanosecondsnanoseconds1970-01-01179297280000000000019UTCGo UnixNano()
Windows FILETIME100 ns ticks1601-01-0113437446400000000018UTC (local time on FAT)NTFS, Active Directory lastLogon, Win32
.NET ticks100 ns ticks0001-01-0163928569600000000018UTC or local, by KindDateTime.Ticks
Excel serialdays1899-12-30463215none: a wall clockExcel, Google Sheets, LibreOffice
Excel 1904days1904-01-01448595none: a wall clockolder Excel for Mac
Mac HFS+seconds1904-01-01387581760010GMT (classic HFS: local)HFS+ file dates
NTP secondsseconds1900-01-01400196160010UTCNTP packets
GPS secondsseconds1980-01-06147700801810no leap seconds: UTC + 18sGPS receivers, RINEX files
Each value is the same instant, October 26, 2026, 00:00 UTC, on its own scale, computed by the engine this page runs. Google Sheets and LibreOffice count days from 1899-12-30 too, so their serials agree with Excel's from March 1, 1900 on. Source: [MS-DTYP] 2.3.3, DateTime.Ticks, Excel, Google Sheets, LibreOffice, TN1150, RFC 5905, RINEX 3.05

Does Unix time count leap seconds?

No. Unix time gives every day exactly 86,400 seconds, so a leap second has no number of its own, and POSIX says so: broken-down POSIX time is not necessarily UTC, despite its appearance.

Since 1972, 27 leap seconds have been added to UTC; Unix time has no number for the extra second, so one timestamp stands for two seconds. The last was on 2016-12-31, and in 2022 the General Conference on Weights and Measures decided that by 2035 the limit that makes them necessary will be raised, which in practice ends them. GPS time, which never had them, shows the difference: it is 18 seconds ahead.

The last seconds of December 31, 1998

UTC23:59:5823:59:5923:59:6000:00:0000:00:01
Unix time915148798915148799915148800915148800915148801
GPS time599184010599184011599184012599184013599184014

Unix time gives 915148800 twice; GPS time, which has no leap seconds, keeps counting.

27 leap secondsnone after December 31, 2016 · none announced before June 28, 2027

before GPS time begansince GPS time began: each one put it a second further ahead

Coordinated Universal Time (UTC) includes leap seconds. However, in POSIX time (seconds since the Epoch), leap seconds are ignored (not applied) to provide an easy and compatible method of computing time differences. Broken-down POSIX time is therefore not necessarily UTC, despite its appearance.

POSIX.1-2024, Rationale A.4.19
Just after this leap second, GPS time ran 13 seconds ahead of UTC. Source: POSIX.1-2024 A.4.19, leap-seconds.list, RINEX 3.05

Unix timestamps in Python, JavaScript, Java, C#, Go, SQL and the shell

Every language converts both ways in a line or two. The traps are the unit (JavaScript and Java count milliseconds) and the time zone (a database may read the value in its session zone).

Each example below turns 817876800 into a date and a date back into seconds, and each was run to check its output. On the shell, macOS and the BSDs take date -r 817876800 while GNU/Linux takes date -d @817876800: the two are not interchangeable.

from datetime import datetime, timezone

t = datetime.fromtimestamp(817876800, tz=timezone.utc)
print(t.isoformat())  # 1995-12-02T04:00:00+00:00

back = datetime(1995, 12, 2, 4, 0, tzinfo=timezone.utc)
print(int(back.timestamp()))  # 817876800

Run with Python 3.14.4 on October 26, 2026: it prints what the comments show.

Each tab is a whole program or session that runs as pasted; in the shell tab, run the half for your system. Source: docs.python.org, ECMA-262, Instant, DateTimeOffset, pkg.go.dev/time, PostgreSQL, MySQL, date(1), GNU Coreutils

Epoch time: questions and answers

What is epoch time?

Epoch time, also called Unix time or a Unix timestamp, is the number of seconds that have passed since 1970-01-01 00:00:00 UTC, not counting leap seconds. Computers store dates this way because one number is easy to compare, sort and send. The timestamp 1000000000 was 2001-09-09 01:46:40 UTC, and the field at the top converts any value into a date.

How do I convert epoch to date, and date to epoch?

Paste the number into the field at the top: the page reads it in every unit, picks the reading that lands on a real date, and shows that date in your time zone and in UTC. For date to epoch, type the date into the same field, or use Date and time → timestamp under it. By hand, new Date(817876800 * 1000) does the first in JavaScript.

What is the current epoch time?

The clock on this page shows the current Unix time live, in seconds, milliseconds, microseconds and nanoseconds, and each value can be copied. It comes from your own device's clock, so it is only as accurate as that clock; a computer that syncs over the internet is usually within a fraction of a second. On the command line, date +%s prints it in seconds.

Is a Unix timestamp in seconds or milliseconds?

Classic Unix timestamps are in seconds, but JavaScript, Java and many web APIs use milliseconds, and some databases and logs use microseconds or nanoseconds. A current timestamp has 10 digits in seconds and 13 in milliseconds. If a date comes out in 1970 or thousands of years from now, the unit is wrong; this page tries every unit and shows which one makes sense.

Why does Unix time start in 1970?

No primary source records the reason. The first Unix manual, from 1971, counted sixtieths of a second from 1 January 1971 and expected to run out within a few years. When the count changed to whole seconds, 1 January 1970 became the start: a round date close to when Unix was being written, from which a 32-bit count of seconds reaches as far as 2038.

Is Unix time the same as UTC?

Almost, but not exactly. Unix time follows UTC's calendar and clock, but it gives every day exactly 86,400 seconds and ignores leap seconds, so a leap second has no timestamp of its own. POSIX itself says a broken-down Unix time is not necessarily UTC. For dates and times people read, the difference never shows; for precise intervals across a leap second, it does.

What is the year 2038 problem?

A Unix time stored as a signed 32-bit number can only reach 2147483647, which is 2038-01-19 03:14:07 UTC. One second later it overflows and reads as December 1901. Modern operating systems use 64-bit time and are safe, but 32-bit fields remain in some databases, file formats and embedded devices: MySQL's TIMESTAMP column, for one, still ends at that second.

Can I convert a date before 1970?

Yes. Dates before 1970 are negative timestamps: -1 is 1969-12-31 23:59:59 UTC, and a date in 1950 is about -631 million. Paste a negative number and the page shows its date; type an older date and it gives you the negative value. Strict POSIX leaves negative values undefined and MySQL's TIMESTAMP can't hold them, but most languages and databases read them as dates before 1970.

How do I convert a Windows FILETIME to a date?

A FILETIME counts 100-nanosecond intervals since 1601-01-01 UTC, so it has 18 digits today. Paste it into the field and the page reads it as a FILETIME alongside the Unix units: 133756272000000000 is 2024-11-09 12:00:00 UTC. By hand, subtract 116444736000000000 and divide by 10,000,000 to get Unix seconds.

How do I convert an Excel date serial to a timestamp?

An Excel serial counts days, with fractions for the time: in the default 1900 system, 45658 is 2025-01-01. Paste the serial and the page reads it as an Excel date in both the 1900 and the 1904 system. Excel treats 1900 as a leap year on purpose, so serials below 61 are a day off, and the page flags them instead of guessing.

Does the converter handle time zones and daylight saving?

Yes. The page shows each date in your own time zone and in UTC, and you can pick any IANA zone, such as America/New_York or Asia/Kolkata. Daylight saving is applied for the date being converted, not for today, so a summer timestamp shows summer time even in winter. A date you type without an offset is read as UTC, and one click reads it in your own zone instead.

Is my timestamp sent anywhere?

No. The conversion runs in your browser, so what you paste never leaves your device and no server sees it. A link made with Copy link carries the timestamp in its address so the page it opens already shows the date; nothing else is stored or sent.

Missing something?Suggest a feature or a new tool