Timestamp Converter - Unix, ISO 8601, RFC 2822 and Any IANA Timezone

Send any timestamp shape, get every representation back at once. Unix seconds, Unix milliseconds (auto-detected), ISO 8601, RFC 2822 date strings, or the literal "now" go in; Unix s and ms, ISO 8601, RFC 2822, a DST-correct rendering in any IANA timezone, day of week, day of year, ISO week number, leap-year flag and humanized relative time come out. Up to 50 per run. $0.0004 per conversion. Unparseable inputs are recorded free.

Log correlation across systems that each picked a different format, scheduling, invoice date handling, and agents that need to reason about "when" without a date library.

What you get

Per input, one record with these exact fields:

• ok - true when the value parsed
• input - the value you sent
• timezone - the IANA zone used for the human rendering
• unixSeconds, unixMillis
• iso8601, rfc2822, utcString
• timezoneFormatted - the same instant rendered in your chosen zone
• dayOfWeek, dayOfYear, weekNumber (real ISO 8601 week rule), isLeapYear
• relativeFromNow - "in 3 days", "2 hours ago" (relative is an alias)
• error - present instead of the conversions when the value could not be parsed. Never charged.

Example 1: a Unix timestamp in a US timezone

Input:

{ "input": 1700000000, "timezone": "America/New_York" }

Output (real run, 2026-08-15):

{
  "input": "1700000000",
  "ok": true,
  "timezone": "America/New_York",
  "unixSeconds": 1700000000,
  "unixMillis": 1700000000000,
  "iso8601": "2023-11-14T22:13:20.000Z",
  "rfc2822": "Tue, 14 Nov 2023 22:13:20 GMT",
  "utcString": "Tue, 14 Nov 2023 22:13:20 GMT",
  "timezoneFormatted": "Tue, Nov 14, 2023, 17:13:20 EST",
  "dayOfWeek": "Tuesday",
  "dayOfYear": 318,
  "weekNumber": 46,
  "isLeapYear": false,
  "relativeFromNow": "2 years ago"
}

22:13 UTC renders as 17:13 EST - the offset comes from real IANA timezone data, so it is correct for that date's DST state rather than a fixed offset.

Example 2: a leap day, and a value that will not parse

Input:

{ "inputs": ["2024-02-29T12:00:00Z", "not-a-date"], "timezone": "America/New_York" }

Output (real run, same session, trimmed):

[
  {
    "input": "2024-02-29T12:00:00Z", "ok": true,
    "unixSeconds": 1709208000,
    "timezoneFormatted": "Thu, Feb 29, 2024, 07:00:00 EST",
    "dayOfWeek": "Thursday", "dayOfYear": 60, "weekNumber": 9, "isLeapYear": true
  },
  { "input": "not-a-date", "ok": false, "error": "unrecognized timestamp/date format" }
]

The bad value does not fail the run and is not charged; the good one converts normally.

When inputs is filled, the single input field is ignored - you are charged for the values you listed and nothing else.

Example 3: mixed shapes in one batch

Input:

{ "inputs": [1516239022, 1700000000000, "2024-01-15", "now"], "timezone": "Asia/Tokyo" }

Seconds, milliseconds, a date string and "now" can be mixed freely - each is detected on its own. 1516239022 is read as seconds and 1700000000000 as milliseconds, because values at or above 1e11 are treated as milliseconds.

Pricing

$0.0004 per timestamp converted. No start fee. One event covers one value parsed and returned in every representation above - Unix s and ms, ISO, RFC 2822, the timezone rendering, all the calendar fields and the relative time. Unparseable inputs are recorded with the reason and never charged.

Honest comparison: a store search on 2026-08-07 for a timestamp converter returned transcript scrapers, not converters - there is no directly comparable paid incumbent to quote a price against, so this sits at the floor of our ladder rather than undercutting a named competitor.

Also honest: every language has a date library, and your own code can do this for free. Pay for it when you want a hosted conversion step in a no-code pipeline, a batch of mixed-format log timestamps normalized in one call, or a tool an AI agent can call instead of doing date arithmetic in its head - which is a thing language models are famously bad at.

When NOT to use this

• Per-row timezones. One timezone applies to the whole run. If each record needs its own zone, send one run per zone, or convert from the iso8601 field on your side.
• Ambiguous local date strings. 03/04/2024 is March 4th or April 3rd depending on where you live, and JavaScript's parser will pick one. Send ISO 8601 for anything that matters.
• Dates before roughly 1973 expressed in milliseconds. The seconds-versus-milliseconds detection is by magnitude, and that is the one region where the two overlap. Send those as ISO strings.
• Date arithmetic. This converts and describes an instant; it does not add business days, compute durations between two timestamps, or handle recurrence rules.
• A single conversion while you are debugging. Any online epoch converter is free. This is for batches, pipelines and agents.

Honest limits

• Unix auto-detection by magnitude: values at or above 1e11 are read as milliseconds, below that as seconds.
• Date-string parsing follows JavaScript Date semantics. ISO 8601 is fully reliable; locale-shaped strings follow JS rules.
• Calendar fields (dayOfWeek, dayOfYear, weekNumber, isLeapYear) are computed in UTC for determinism, while timezoneFormatted renders in your chosen zone. Near midnight these can therefore describe different calendar days - by design, so the calendar fields never depend on a zone you did not intend.
• relativeFromNow is computed at run time, so it ages the moment the run finishes.
• Up to 50 inputs per run. An invalid timezone name stops the run with a guidance record rather than silently substituting UTC.

FAQ

How do I convert a Unix timestamp to a readable date with a timezone? Send {"input": 1700000000, "timezone": "America/New_York"}. timezoneFormatted is the human form; iso8601 is the machine form. Any IANA zone name works.

Does it handle both seconds and milliseconds? Yes, automatically, and both are always returned as unixSeconds and unixMillis so you can see which way it read your input. If the ISO date comes back in 1970 or in the year 50,000, your value was in the other unit - resend it as ISO.

Which week number does it use? Real ISO 8601: weeks start on Monday and week 1 is the week containing the first Thursday. That means January 1st can correctly be week 52 or 53 of the previous year, and this gets that right rather than dividing the year by seven.

Is daylight saving time handled correctly? Yes. Rendering goes through Intl with real IANA timezone data, so an instant in July renders as EDT and one in November as EST, with the correct offset for each.

Can I convert a batch of log timestamps at once? Yes - up to 50 per run in inputs, and the shapes can be mixed (seconds, milliseconds, ISO strings, "now"). One record and one charge each; unparseable values are free.

What does "now" do? Returns the current instant in every representation. Useful as a clock for an agent, or to get the current ISO week number without any date math.

Why did some rows come back ok: false? The value could not be parsed as a timestamp or a date. It is recorded with the reason and never charged.

Use from code or AI agents

curl -s "https://api.apify.com/v2/acts/EliAI~timestamp-converter/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -X POST -H 'Content-Type: application/json' \
  -d '{"input": "now", "timezone": "Asia/Tokyo"}'

Agents: connect Apify MCP and call the EliAI/timestamp-converter tool.

• Capability: convert any timestamp shape into every standard representation plus calendar facts, timezone-aware
• Required input: input or inputs; optional timezone (IANA, default UTC)
• Returns: one record per input with all representations
• Bounded: 50 inputs per run; failures isolate per input
• Side effects: none