Timestamp Converter guide
How the XGM Timestamp Converter reads Unix seconds, milliseconds, ISO 8601 and RFC 2822 dates, converts time zones and avoids common date bugs.
What a Unix timestamp is
Unix time is the number of seconds that have passed since the Unix epoch, 1970-01-01 00:00:00 UTC, not counting leap seconds. It is a single number without a time zone, which makes it convenient for storing and comparing moments. 1789462800 is the same instant everywhere in the world; only its local clock reading differs.
Different systems count in different units. Classic Unix APIs and JWT claims use seconds, JavaScript's Date.now() returns milliseconds, some databases and Go use microseconds or nanoseconds. Mixing them up is one of the most common date bugs: a millisecond value read as seconds lands tens of thousands of years in the future.
How to use the Timestamp Converter
- Open the Timestamp Converter and enter a Unix timestamp or a date, or leave the field empty for the current time.
- Check the detected unit, and the moment in UTC and in your own time zone.
- Pick another time zone to see the local clock time there, for example for a meeting or an incident timeline.
- Copy the format you need: Unix seconds, milliseconds, ISO 8601 or RFC 2822.
| Digits (for current dates) | Unit | Example |
|---|---|---|
| 10 | Seconds | 1789462800 |
| 13 | Milliseconds | 1789462800000 |
| 16 | Microseconds | 1789462800000000 |
| 19 | Nanoseconds | 1789462800000000000 |
Detection by size works for dates in a normal range around today. Very old or very far future values can be ambiguous; if the result looks wrong, check the unit your source system uses.
Reading a cron expression
Switch the page to Explain a cron expression and paste the line from your crontab. The tool reads standard (Vixie) cron: five fields - minute, hour, day of month, month, day of week - or six when the first one is seconds. It says in plain English when the schedule fires and lists the next five runs, in the time zone you select and in UTC.
| Field | Range | Also accepts |
|---|---|---|
| Second (only in the six-field form) | 0-59 | *, ranges, lists, steps |
| Minute | 0-59 | */15, 1-30/2, 5,20,35 |
| Hour | 0-23 | *, 9-17, */2 |
| Day of month | 1-31 | ?, ranges, lists, steps |
| Month | 1-12 | JAN-DEC |
| Day of week | 0-7 | SUN-SAT; 0 and 7 both mean Sunday |
Two rules trip people up. First, when both the day-of-month and the day-of-week field are restricted, standard cron runs when either matches: 0 0 13 * 5 runs on every Friday and on the 13th of every month, not only on Friday the 13th. Leave one of the two as * when you mean the overlap. Second, cron fires in the time zone of the machine it runs on, so the runs listed here - counted from your own browser clock - only match your server when you pick the server's zone.
L, W and # are Quartz extensions rather than standard cron. The tool names the token it did not understand and refuses instead of guessing, and an expression that can never fire - 30 4 31 2 *, the 31st of February - is reported as impossible rather than given five invented dates.
Date formats
| Format | Example | Where |
|---|---|---|
| ISO 8601 / RFC 3339 | 2026-09-15T09:00:00Z, 2026-09-15T12:00:00+03:00 | APIs, JSON, logs |
| RFC 2822 / RFC 5322 | Tue, 15 Sep 2026 09:00:00 +0000 | Email Date headers, RSS |
| HTTP date (RFC 9110) | Tue, 15 Sep 2026 09:00:00 GMT | HTTP Date, Expires, Last-Modified |
| Unix seconds | 1789462800 | Databases, JWT exp, Unix tools |
| Unix milliseconds | 1789462800000 | JavaScript, many event systems |
RFC 3339 is a strict profile of ISO 8601 designed for internet protocols: always a full date and time with seconds and an explicit offset or Z for UTC. If you design an API, use RFC 3339 strings or Unix seconds and document which one.
# seconds to date (GNU date)
date -u -d @1789462800
# macOS / BSD date
date -u -r 1789462800
# current Unix time in seconds and milliseconds
date +%s
node -e 'console.log(Date.now())'Time zones and daylight saving
A time zone is more than an offset. Europe/Bucharest is UTC+2 in winter and UTC+3 in summer, and the dates of the switch have changed over the years. That is why converting with a named zone from the IANA time zone database is safer than adding a fixed number of hours.
| Zone | Local time for 2026-09-15T09:00:00Z |
|---|---|
| UTC | 09:00 |
| Europe/London | 10:00 (BST, UTC+1) |
| Europe/Bucharest | 12:00 (EEST, UTC+3) |
| America/New_York | 05:00 (EDT, UTC−4) |
| Asia/Tokyo | 18:00 (JST, UTC+9) |
Local times that do not exist or exist twice
Timestamps in logs and incident timelines
During an incident, events come from many systems: load balancer logs in UTC, application logs in local time, a monitoring alert with a Unix timestamp and an email with an RFC 2822 date. Building a timeline means converting all of them to one zone, usually UTC, before sorting. The converter helps with the odd formats; configuring every system to log in UTC with an offset avoids most of the work.
- Log in UTC with an explicit
Zor offset in every line. - Include milliseconds, so events within the same second can be ordered.
- Keep server clocks synchronised with NTP; a few seconds of drift reorders events.
- When sharing a timeline, state the zone once at the top and use it throughout.
Common date and time bugs
- Seconds versus milliseconds. A date in 1970 or in the year 57,000 usually means the unit was wrong.
- Dates without an offset.
2026-09-15 09:00is ambiguous; different systems read it as UTC or local time. - Storing local time. Store UTC and the user's time zone separately; derive local times for display.
- Parsing month and day order.
09/10/2026is September 10 in the US and 9 October in most of Europe; use ISO 8601 for data. - Clock skew between servers. Token validation and log correlation break when clocks drift; keep servers synchronised with NTP.
- Year 2038. Signed 32-bit Unix seconds overflow on 2038-01-19; use 64-bit time values in storage and code.
Timestamps appear in many other tools too: exp and iat claims in the JWT Decoder, Received header dates in the Email Header Analyzer and the embedded time of v7 identifiers in the UUID Generator. The time for a log line from api.example.com means the most when all of them use UTC.
FAQ
What is the Unix epoch?
1970-01-01 00:00:00 UTC. Unix timestamps count seconds from that moment, ignoring leap seconds.
How do I know if a timestamp is in seconds or milliseconds?
For current dates, 10 digits are seconds and 13 digits are milliseconds. The converter detects this automatically and shows the unit it used.
Does a Unix timestamp have a time zone?
No. It identifies an instant. Time zones only matter when you turn it into a local date and clock time.
Why is my converted time off by exactly some hours?
The value was interpreted as local time instead of UTC, or the reverse. Make sure date strings include Z or an offset.
What is the ISO week number?
Weeks start on Monday, and week 1 is the week containing the first Thursday of the year. It is common in business planning in Europe.
Does the converter use my computer's clock?
Yes, for "now" and for relative times such as "in 3 hours". If your clock is wrong, those values are wrong too.
What happens in 2038?
Systems that store Unix seconds in signed 32-bit integers overflow on 19 January 2038. Modern 64-bit systems and languages are not affected.
Are leap seconds counted?
No. Unix time treats every day as exactly 86,400 seconds, so leap seconds are not represented.
Why does JavaScript show a different month?
In JavaScript's Date API, months are numbered from 0, so January is 0 and September is 8. Use formatting functions or ISO strings instead of building dates from numbers by hand.
Which format should an API use?
RFC 3339 strings in UTC, such as 2026-09-15T09:00:00Z, or Unix seconds. Pick one, document it and use it everywhere.