Free Timestamp Converter API Endpoint

Calling the free timestamp converter API endpoint

The body carries a single field named data. Start with a date string.

curl -X POST https://aisenseapi.com/services/v1/timestamp_convert \
  -H "Content-Type: application/json" \
  -d '{"data":"2026-08-19T20:28:10+00:00"}'

{"input":"2026-08-19T20:28:10+00:00","detected":"datetime","timestamp":1787171290,"datetime":"2026-08-19T20:28:10+00:00","rfc2822":"Wed, 19 Aug 2026 20:28:10 +0000","utc_datetime":"2026-08-19T20:28:10+00:00"}

Now send the number instead. The same instant comes back, and detected reports how the value was read.

curl -X POST https://aisenseapi.com/services/v1/timestamp_convert \
  -H "Content-Type: application/json" \
  -d '{"data": 1787171290}'

{"input":1787171290,"detected":"unix","timestamp":1787171290,"datetime":"2026-08-19T20:28:10+00:00","rfc2822":"Wed, 19 Aug 2026 20:28:10 +0000","utc_datetime":"2026-08-19T20:28:10+00:00"}

There is no direction flag here, and no separate parse and format endpoints to pick between. The two calls above are the same call with a different value in data. Code holding a mixed pile of times can push all of it through without branching first.

What comes back

Field	Type	Description
input	string or number	The value you sent, echoed back unchanged. It makes the response self-describing in a log: the line shows what was asked as well as what was answered.
detected	string	How the input was read: `unix`, `unix_ms`, `datetime` or `now`. This is the field to check when a result looks wrong.
timestamp	integer	Whole seconds since the Unix epoch, midnight UTC on 1 January 1970. Fractions are dropped, not rounded up.
datetime	string	ISO 8601 with an explicit offset. UTC unless you asked for an offset.
rfc2822	string	The format email headers and HTTP dates use, for example `Wed, 19 Aug 2026 20:28:10 +0000`.
utc_datetime	string	The same instant normalised to UTC. Always `+00:00`, whatever went in and whatever offset you asked for.

All five outputs describe one instant. The timestamp field is whole seconds, and the calendar fields are that same moment written three ways. When datetime and utc_datetime differ, only the wall-clock presentation differs, never the moment.

How the input is detected

There is no format parameter, so the service works out what it received by looking at the value. Detection is the one decision the free timestamp converter API endpoint makes on your behalf, which is why it reports that decision back to you. The rules are short and worth knowing.

Numbers are epoch seconds
A number, or a string of digits such as "1787171290", is read as Unix seconds and reported as unix. Thirteen digits and up are read as milliseconds instead and reported as unix_ms, which is what JavaScript's Date.now() produces. The millisecond value is divided down, so timestamp stays whole seconds.
Everything else is parsed as a date
ISO 8601, RFC 2822 and plain calendar dates all parse and report datetime. A date with no time component becomes midnight. A datetime with no offset is taken as UTC rather than as the server's local zone.
The literal string now
Sending "now" converts the server's current clock reading and reports now. It saves a round trip when you want the present moment in every format at once. For the bare current epoch second and nothing else, the Timestamp API endpoint is the smaller call.
Anything unparseable is refused
Input the parser cannot make sense of returns HTTP 400 rather than a guess: {"error":"Unrecognized datetime format. Send a unix timestamp, an ISO 8601 or RFC 2822 datetime, or \"now\"."}. An empty request body returns 400 in the same shape.

The split between seconds and milliseconds is the rule that catches people out. A ten-digit number and a thirteen-digit number look alike in a config file, yet they sit three orders of magnitude apart in meaning. A millisecond value read as seconds lands tens of thousands of years in the future. That is what detected exists for. When a converted date looks absurd, read detected before you suspect the arithmetic. Sources that emit microseconds have their own reading in the Microtimestamp API endpoint.

Rendering at a fixed offset

By default the calendar fields come back in UTC. Add an offset field, written as four digits with an optional leading sign, to render them at a fixed offset instead.

curl -X POST https://aisenseapi.com/services/v1/timestamp_convert \
  -H "Content-Type: application/json" \
  -d '{"data": 1787171290, "offset": "0200"}'

{"input":1787171290,"detected":"unix","timestamp":1787171290,"datetime":"2026-08-19T22:28:10+02:00","rfc2822":"Wed, 19 Aug 2026 22:28:10 +0200","utc_datetime":"2026-08-19T20:28:10+00:00"}

Only datetime and rfc2822 move. The timestamp and utc_datetime fields describe the instant itself and stay put, which keeps a response safe to log and compare across callers who asked for different offsets. Remember that this is a fixed shift and not a timezone, so it knows nothing about daylight saving. Resolve a named zone with the Timezones API endpoint first, then pass the offset it hands back.

Where it earns its place

Reading a time out of a log

A log line or a database column holds a bare ten-digit number. Post it and read the date back, without opening a console or trusting a conversion done in your head.

Date headers

Take rfc2822 straight from the response for an email Date header or an HTTP date field, in the exact form those specifications expect.

Normalising mixed feeds

Sources arrive as epoch seconds, epoch milliseconds and half a dozen date strings. Push each one through, store timestamp and utc_datetime, and everything downstream sees one shape.

Agents without date code

Let a language model convert a time with one request instead of generating date arithmetic that is hard to review and easy to get wrong.

Sanity-checking a stored value

Convert the value and compare detected against what the column was supposed to hold. Milliseconds sitting in a seconds column show up straight away.

Privacy, caching and limits

The value travels in the POST body, not the URL, so it never turns up in a request path or a proxy log. The conversion is arithmetic on the value you sent and depends on nothing else about the caller.

Conversions are deterministic, so a result for a fixed input and offset is safe to cache indefinitely. The one exception is "now", which reads the server clock and must never be cached. The free timestamp converter API endpoint asks for no key and no account, and the service-wide limit is 5000 requests per IP per 24 hours.