Call the free datetime api endpoint
Ask for the time and one field comes back:
curl https://aisenseapi.com/services/v1/datetime{"datetime":"2026-08-19T20:28:10+00:00"}The default reading is UTC. Add an offset as a path segment and the same call returns the same instant written for that offset:
curl https://aisenseapi.com/services/v1/datetime/+0200{"datetime":"2026-08-19T22:40:39+02:00"}Two things moved. The wall clock time jumped two hours, and the suffix changed from +00:00 to +02:00. The instant itself did not move at all.
Response field
| Field | Type | Description |
|---|---|---|
| datetime | string | ISO 8601 with an explicit offset. UTC unless you asked for another offset in the path. |
Responses carry content-type: application/json and cache-control: no-store. A clock reading has no shelf life, so nothing in front of the service should be allowed to repeat an old answer.
The offset goes in the path
The free datetime api endpoint has exactly one optional parameter, and it is a path segment rather than a query string. The signature is GET /datetime[/{offset}]. Write the offset as four digits with an optional leading sign, the way ISO 8601 writes it: +0200, 0530, -0500.
curl https://aisenseapi.com/services/v1/datetime/-0500{"datetime":"2026-08-19T17:33:55-05:00"}Accepted values run from -1200 to 1200. A four-digit value outside that range quietly falls back to +00:00 rather than failing, so read the offset back out of the response whenever you passed one in.
A segment that is not four digits is not an offset. The router sees an unknown route and says so:
curl https://aisenseapi.com/services/v1/datetime/130{"error":"Unknown endpoint. See https:\/\/www.aisense.no\/free-public-apis for the reference."}Note the shape of what you are asking for. An offset is a fixed shift, not a timezone. It has no opinion about daylight saving, so +0200 in January and +0200 in July mean exactly the same arithmetic. When you need named zones such as Europe/Oslo, the Timezones API Endpoint returns the full list with each zone's current offset.
When a calendar string beats an epoch integer
An epoch integer and an ISO 8601 string name the same instant. They are not interchangeable in practice, because they fail in different places. Three cases pick the string every time.
- Anything a human reads
The number 1787171289 tells a person nothing. The string 2026-08-19T20:28:10+00:00 tells them the date, the time and the zone at a glance. Status pages, health checks, receipts, error bodies and support tickets are all read by people, and a calendar string removes the conversion step between the reader and the answer.
- Anything that gets logged
Log lines outlive the incident that produced them. An ISO 8601 stamp sorts lexicographically in the same order it sorts chronologically, so plain text tools put the file in time order without parsing a thing. Grep for a date prefix and you have narrowed to a day.
- Anything a date library parses directly
ISO 8601 is the format standard parsers accept without being handed a format string. JavaScript, Python, Go and Java read it as it stands, offset included, so the value arrives as a date object instead of a bare number you still have to interpret.
The integer keeps its own territory. Ten ASCII digits fit in a URL, a filename, an environment variable or a narrow database column, they carry no zone to argue about, and arithmetic on them is just subtraction. Read one from the Timestamp API Endpoint, or take the same instant with a microsecond fraction from the Microtimestamp API Endpoint when two events land inside the same second and you need to keep their order.
Store the integer, show the string. That rule survives contact with most codebases, and the free datetime api endpoint covers the showing half of it. To move a value between the two shapes after the fact, the Timestamp Converter API Endpoint takes either one, works out which it received, and returns both.
What the string is made of
Read 2026-08-19T20:28:10+00:00 in three pieces. First the calendar date, then the letter T as a separator, then the wall clock time, then the offset from UTC. The offset is the part that carries the meaning. Drop it and you have a time that is only correct in one place on earth, and a reader has no way to tell which place that is.
Common uses
Status output
Stamp a health response or status page with a value a reader can check against their own watch, with no conversion tool in the way.
Structured logs
Write the string into a log field so the file sorts chronologically as plain text and stays readable when a line is pasted into a ticket.
Thin clients
Give a shell script, a browser page or an embedded board a correct calendar time without shipping a date library or trusting a battery-backed clock.
Reports in a local offset
Ask for the offset your reader works in, then print the value exactly as it arrives instead of converting UTC in application code.
Drift checks
Compare the server reading against the local clock at startup and fail loudly when the gap is wide, before it resurfaces later as an authentication error.
Privacy and limits
The free datetime api endpoint takes no input beyond the optional offset, so the request holds nothing about the caller worth storing. The answer depends only on the server clock.
The base URL is https://aisenseapi.com/services/v1. There is no key, no account and no sign-up step. The service-wide limit is 5000 requests per IP per 24 hours, which is generous for stamping and drift checks and is not meant to carry a polling loop.
Sibling clock endpoints share that budget. They are grouped on the Time APIs hub, and every endpoint in the collection is listed on the Free public REST APIs reference.