--- title: Rate limited until 1791068136? Convert it with the Timestamp Converter description: An API says you're rate limited until 1791068136, a log line starts with 1791065206319, and you need to know when that is in your own time. A Unix timestamp counts seconds since 1 January 1970 UTC; convert it and you get a date in UTC and in your timezone. Here's a real case from the GitHub API, how to spot a seconds-versus-milliseconds mix-up, and the date commands that do the same. canonical: https://watchfor.io/blog/how-to-convert-a-unix-timestamp --- # Rate limited until 1791068136? Convert it with the Timestamp Converter 2026-10-04 · WatchFor Team · Guides · guides, api, devops An API says you're rate limited until 1791068136, a log line starts with 1791065206319, and you need to know when that is in your own time. A Unix timestamp counts seconds since 1 January 1970 UTC; convert it and you get a date in UTC and in your timezone. Here's a real case from the GitHub API, how to spot a seconds-versus-milliseconds mix-up, and the date commands that do the same. To convert a Unix timestamp to a date, count it as seconds since 1970-01-01 00:00:00 UTC: 1791068136 is 2026-10-03 22:55:36 UTC, which is 18:55:36 in New York. Ten digits means seconds, thirteen means milliseconds; reading one as the other lands you in 1970 or tens of thousands of years in the future. The free [Timestamp Converter](/unix-timestamp-converter) does both directions in the browser: paste a number and get UTC, your local time and "in 49 minutes"; pick a date and get its timestamp in seconds and milliseconds. It detects the unit from the number of digits. ## What this tool answers *When is this number, in a time I can read?* And the reverse: *what number do I put in an API call for this date?* Reach for it when a response header, a log line, a database column or a token carries a timestamp, when a date displays as 1970, or when an API wants `since=` or `until=` as epoch seconds and you need the value for a specific moment. ## A real example ### Converting a Unix timestamp from an API rate-limit header Every response from the GitHub REST API carries rate-limit headers. Without a token you get 60 requests an hour, and once they're gone the API refuses you until the window resets. We asked how much was left: ```bash curl -sI https://api.github.com/users/octocat | grep -iE '^date|x-ratelimit' ``` ```text date: Sat, 03 Oct 2026 21:59:06 GMT x-ratelimit-limit: 60 x-ratelimit-remaining: 55 x-ratelimit-used: 5 x-ratelimit-resource: core x-ratelimit-reset: 1791068136 ``` `x-ratelimit-reset` is documented as UTC epoch seconds. We pasted it into the [Timestamp Converter](/unix-timestamp-converter) on a machine set to New York time, and also picked midnight on 1 October in the date field, for a query we'll come back to: ![The Timestamp Converter with 1791068136 entered: detected unit seconds, UTC 2026-10-03T22:55:36Z, local America/New_York Sat Oct 3 2026 18:55:36, relative in 49 minutes; on the right, 10/01/2026 12:00 AM local converts to 1790827200 seconds, 2026-10-01T04:00:00Z](/blog/how-to-convert-a-unix-timestamp-result.webp) - **Detected unit: seconds** (10 digits). - **UTC 2026-10-03T22:55:36Z**, local **Sat, Oct 3, 2026, 18:55:36** in America/New_York. - **Relative: in 49 minutes**, measured against the clock at the top (1791065206 when the screenshot was taken). **The answer:** the limit resets at 22:55:36 UTC, 18:55 in New York, 49 minutes after we looked. A script that hits the limit should sleep until `reset − now` seconds have passed instead of retrying in a loop, which burns nothing but time and log space. The right-hand card shows the other direction, and the most common mistake with it. **Midnight on 1 October in New York is 1790827200** (`2026-10-01T04:00:00Z`). Midnight UTC is 1790812800, four hours (14,400 seconds) earlier. If an API wants "everything since the 1st" and counts days in UTC, the local value silently drops the first four hours. ## How to read the results | What you see | What it means | | --- | --- | | **Current Unix timestamp** | Now, in seconds (large) and milliseconds (small), ticking every second. Compare lengths with your number to spot a unit mix-up at a glance. | | **Detected unit** | Guessed from the digits before any decimal point: up to 11 seconds, up to 14 milliseconds, up to 17 microseconds, longer nanoseconds. | | **UTC** | The moment in ISO 8601 with a `Z` suffix. This is the value to paste into tickets and incident timelines. | | **Local (zone)** | The same moment in your browser's timezone, named in brackets. Someone elsewhere sees a different clock time for the same number. | | **Relative** | How far the moment is from now: "in 49 minutes", "3 days ago". | | **Seconds / Milliseconds** | The value normalised to both units, ready to copy into code that expects the other one. | | **Date → timestamp** | Takes a date and time in **your local timezone** and returns seconds, milliseconds and the UTC equivalent. | | **Not a number / Out of representable date range** | The input has letters or separators, or is beyond what a JavaScript date can hold (about 273,000 years either side of 1970). | ## More ways to use it - **Decoding a log line.** Many logs and queues (Kafka, CloudWatch, JSON loggers) stamp events in milliseconds. Paste the 13-digit value and the converter reads it as milliseconds. - **Building an incident timeline.** Convert every timestamp from every system to UTC first, then sort. Mixing local times from three tools is how a timeline ends up with the fix before the failure. - **A date shows up as 1970.** A millisecond field treated as seconds or the reverse; paste the raw number and see which unit makes sense. - **Setting an expiry.** Signed URLs, cache headers and tokens often take an absolute epoch; pick the date on the right and copy the seconds. [Epoch time in JWTs](/blog/how-to-convert-epoch-time) has the token case. ## Tips and gotchas - **Check the unit first, always.** `1791068136` read as milliseconds is 21 January 1970, 17:31:08 UTC. `1791068136000` read as seconds is 10 September of the year 58726. Either one in a UI means a unit bug, not bad data. - **Timestamps have no timezone.** The number means the same instant everywhere; only the display changes. Store and send epoch values or ISO 8601 with an offset, and convert to local time at the last moment. - **The date field uses your browser's zone.** To get the timestamp for a UTC moment, either set it accordingly or convert with `date -u`, as below. - **Leap seconds don't exist in Unix time.** Every day is exactly 86,400 seconds, so differences between two timestamps can be off by the leap seconds in between. For nearly all application work that doesn't matter. - **32-bit fields run out in 2038.** A signed 32-bit integer stops at 2147483647, 2038-01-19 03:14:07 UTC. Old databases, file formats and embedded devices can still have such fields. ## Check it from the command line too GNU `date` (Linux) converts both ways: ```bash date -u -d @1791068136 TZ=America/New_York date -d @1791068136 ``` ```text Sat Oct 3 10:55:36 PM UTC 2026 Sat Oct 3 06:55:36 PM EDT 2026 ``` From a date to a timestamp, with the timezone made explicit: ```bash TZ=America/New_York date -d '2026-10-01 00:00' +%s date -u -d '2026-10-01 00:00' +%s ``` ```text 1790827200 1790812800 ``` Both match the converter. On macOS, `date -r 1791068136` converts to a date and `date -j -f '%Y-%m-%d %H:%M' '2026-10-01 00:00' +%s` goes the other way. `date +%s` prints the current timestamp. In code: `Math.floor(Date.now() / 1000)` in JavaScript, `int(time.time())` in Python. ## Keep watching it The number behind this example can be watched continuously. A [WatchFor API monitor](/api-monitoring) can call `https://api.github.com/rate_limit` (or your own API's quota endpoint) on a schedule, extract `resources.core.remaining` as a metric and chart it over time, and alert when the endpoint stops answering with a 2xx. The [API monitoring guide](/blog/api-monitoring-guide) covers what else is worth asserting on, and [JSON formatting and JSONPath](/blog/how-to-format-and-query-json) shows how to find the field paths. ## FAQ **How do I convert a Unix timestamp to a date?** Treat it as seconds since 1970-01-01 00:00 UTC. Paste it into a [timestamp converter](/unix-timestamp-converter), run `date -u -d @` on Linux, or use `new Date(n * 1000)` in JavaScript. **Is my timestamp in seconds or milliseconds?** Count the digits. Dates in this era are 10 digits in seconds and 13 in milliseconds. JavaScript's `Date.now()` and Java's `System.currentTimeMillis()` return milliseconds; Unix tools, PHP and most HTTP headers use seconds. **Why does my timestamp convert to 1970?** A seconds value was read as milliseconds, so it lands a few weeks after the epoch. Multiply by 1,000 before passing it to something that expects milliseconds, such as JavaScript's `Date`. --- Canonical page: https://watchfor.io/blog/how-to-convert-a-unix-timestamp · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt