How to use the Unix timestamp converter
- Paste a timestamp into the Unix timestamp box. It is read as seconds or milliseconds from its size (see below), or choose the unit yourself.
- Or pick a date and time and choose whether it is your local time or UTC. The timestamp box fills in, in seconds.
- Read the result on the right: the date in UTC and in your time zone, ISO 8601 forms, and the value in seconds and milliseconds. The Discord codes under the form update too.
The current Unix time at the top runs live, in seconds and milliseconds. Copy takes the value at the moment you click.
What a Unix timestamp is
A Unix timestamp (also called epoch time or POSIX time) is the number of seconds since the Epoch, which POSIX defines as "zero hours, zero minutes, zero seconds, on January 1, 1970 Coordinated Universal Time (UTC)". It is the same number everywhere in the world at the same moment; time zones only change how it is shown.
Leap seconds are not counted. POSIX says that in seconds since the Epoch "each and every day shall be accounted for by exactly 86400 seconds". That makes the arithmetic simple: a timestamp divided by 86,400 is the number of whole days since 1 January 1970.
| Timestamp | Date and time (UTC) |
|---|---|
-1 | 31 December 1969, 23:59:59 |
0 | 1 January 1970, 00:00:00 |
1000000000 | 9 September 2001, 01:46:40 |
1700000000 | 14 November 2023, 22:13:20 |
2000000000 | 18 May 2033, 03:33:20 |
2147483647 | 19 January 2038, 03:14:07 |
Worked example: 1,700,000,000 divided by 86,400 is 19,675 days with 80,000 seconds left over. 19,675 days after 1 January 1970 is 14 November 2023, and 80,000 seconds is 22 hours, 13 minutes and 20 seconds. Negative timestamps count back from 1970.
Seconds or milliseconds?
Many systems store time in milliseconds instead of seconds, which adds three digits. In Auto, the converter looks at the size of the number, ignoring any minus sign:
| Size of the number | Read as | Typical length today |
|---|---|---|
| Below 100,000,000,000 | Seconds | 10 digits |
| Below 100,000,000,000,000 | Milliseconds | 13 digits |
| Below 100,000,000,000,000,000 | Microseconds | 16 digits |
| Larger | Nanoseconds | 19 digits |
The cut-off works because 100,000,000,000 seconds is far in the future (the year 5138), while 100,000,000,000 milliseconds is only 3 March 1973. So any date from 1973 to the year 5138 is read correctly. A millisecond value from 1970 to early 1973 is too small to tell apart from seconds: choose ms by hand for those. Micro and nanosecond values keep every digit in the result, although the date itself is shown to the millisecond.
Discord timestamps
Discord turns a code like <t:1618953630:R> in a message into a date that each reader sees in their own time zone. Discord's developer documentation says: "Timestamps are expressed in seconds and display the given timestamp in the user's timezone and locale." The format is <t:TIMESTAMP:STYLE>, and <t:TIMESTAMP> with no style uses the default, f.
| Style | Name in Discord's docs | Docs example |
|---|---|---|
t | Short Time | 16:20 |
T | Medium Time | 16:20:30 |
d | Short Date | 20/04/2021 |
D | Long Date | April 20, 2021 |
f | Long Date, Short Time (default) | April 20, 2021 at 16:20 |
F | Full Date, Short Time | Tuesday, April 20, 2021 at 16:20 |
s | Short Date, Short Time | 20/04/2021, 16:20 |
S | Short Date, Medium Time | 20/04/2021, 16:20:30 |
R | Relative Time | 4 years ago |
The examples are for 1618953630, which is 21:20:30 UTC on 20 April 2021; the docs show it as 16:20, the same moment in US Central time. The letters are case sensitive: t and T are different styles. The previews on this page use your browser's language settings, so they can look slightly different from Discord's.
The most common mistake is pasting milliseconds. Discord needs seconds, so the codes here always use whole seconds, whatever unit you typed.
The year 2038 problem
Older software often stored Unix time in a 32-bit signed integer, whose largest value is 2,147,483,647. That is 03:14:07 UTC on 19 January 2038. One second later, the number no longer fits. The GNU Gnulib manual describes the year 2038 problem as "unpredictable behaviour that will likely occur in the year 2038, for programs that use a 32-bit signed integer 'time_t' type", which "cannot represent timestamps on or after 2038-01-19 03:14:08 UTC".
The smallest 32-bit value, -2,147,483,648, is 20:45:52 UTC on 13 December 1901. The converter shows a note when a timestamp is outside that range, which helps when you are testing how a system handles dates after 2038.
Questions and answers
What is the current Unix timestamp?
It is shown live at the top of the converter, in seconds and in milliseconds, from your device's clock. If your device clock is wrong, the value will be off by the same amount.
Does a Unix timestamp depend on the time zone?
No. A Unix timestamp counts seconds from a fixed moment in UTC, so it is the same number everywhere at the same moment. Only the way it is shown as a date changes with the time zone.
How do I tell seconds from milliseconds?
Count the digits. Timestamps from September 2001 onward are 10 digits in seconds and 13 in milliseconds. The converter does this for you and says which it chose; pick a unit to override it.
Why does my Discord timestamp show the wrong date?
Usually because the number is in milliseconds. Discord expects seconds, so a 13-digit value lands tens of thousands of years in the future. Copy a code from this page, which always uses seconds.
Are leap seconds included?
No. Unix time treats every day as exactly 86,400 seconds, as POSIX defines it, so leap seconds are not counted.
Is anything I enter sent anywhere?
No. All conversions run in this page with your browser's own clock and settings. Nothing is sent or stored.
Sources
Checked on 7 October 2026. If a rule has changed, please tell us.