Convert between time zones
Noon UTC on 21 July 2026 is 2:00 p.m. in Madrid and 6:00 a.m. in Costa Rica: convert a moment between two time zones with the daylight-saving rules that apply on that exact date. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Datetime
- 2026-07-21T12:00:00Z
- Source period or zone
- Europe/Madrid
- Target period or zone
- America/Costa_Rica
- UTC time
- 2026-07-21T12:00:00.000Z
- Source period or zone
- 2026-07-21, 2:00:00 p.m. GMT+2
- Target period or zone
- 2026-07-21, 6:00:00 a.m. CST
A meeting scheduled 'at 9am Eastern' means something different in January than it does in July, and a naive UTC-offset shift gets it wrong twice a year for anyone still using one.
Why a fixed offset goes wrong
It is tempting to store UTC-5 next to a time and call it done, but that number is only true for part of the year in most of North America and Europe. In places like Arizona or most of the southern hemisphere, daylight saving either does not apply or runs on the opposite schedule. The rules also change: governments move the start and end dates and sometimes abolish daylight saving altogether, so a hardcoded table quietly goes stale. This converter works with named zones such as New York or Kolkata and the current rules for each region, so the hour you send is the hour that shows up on the other end.
Where an exact conversion matters
A meeting set for 9 a.m. Eastern means a different moment in January than in July, and a simple offset shift gets it wrong twice a year. The same date-aware rule keeps a weekly call anchored to the organizer's morning while attendees elsewhere move in and out of daylight saving on other dates. It shows a traveler the local arrival time of a flight, puts timestamps from servers in several regions on one reference clock before an incident review, and lets a shop show order and delivery times in the customer's own local time. It also handles the rare moment when a clock skips an hour or repeats one.
Why fixed offsets are a trap
It is tempting to store 'UTC-5' next to a timestamp and call it done, but that number is only true for part of the year in most of North America and Europe, and it is never true at all in places like Arizona or most of the southern hemisphere, where daylight saving either does not apply or runs on the opposite schedule. Worse, the rules themselves change: governments adjust DST start and end dates, and occasionally abolish it entirely, so a hardcoded offset table quietly goes stale.
What you can do with it
Displaying flight and travel times
Convert a departure timestamp into the arrival city's local time, correctly accounting for whichever side of a DST transition each city currently sits on.
Scheduling recurring meetings
Keep a weekly call anchored to 9am in the organizer's local zone even as attendees in other regions shift in and out of daylight saving on different dates.
Normalizing server logs across regions
Convert timestamps from distributed servers into a single reference zone before merging logs for analysis or incident timelines.
Localizing e-commerce order times
Show customers their order confirmation and delivery estimates in their own local time, converted accurately from the warehouse's operating zone.
FAQ
What timezone identifiers does it accept?
Standard IANA zone names such as America/New_York, Europe/Madrid or Asia/Tokyo, which unambiguously identify a region's full historical and current DST rules, unlike abbreviations like EST or CST.
Does it handle the exact moment a DST transition happens?
Yes, including the edge cases where a clock skips an hour in spring or repeats an hour in fall, so conversions right at the transition boundary remain accurate.
What happens if a country changes its DST rules?
The underlying zone data is kept current with official government changes, so conversions reflect the latest rules rather than an outdated, hardcoded table.
What if my request fails or the zone identifier is invalid?
The task is retried automatically up to three times; if it still cannot complete, you receive a clear error and are not charged.
Why does the same city convert differently in July and December?
Because the offset depends on the date. Most of North America and Europe use daylight saving time for only part of the year, so a fixed figure like UTC-5 is right for some months only; the converter applies the rule for that specific day.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/dev/timezone \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"datetime":"2026-07-17T12:00:00Z","from":"UTC"}'const res = await fetch("https://api.kit.forhosting.com/dev/timezone", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"datetime": "2026-07-17T12:00:00Z",
"from": "UTC"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/timezone",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"datetime": "2026-07-17T12:00:00Z",
"from": "UTC"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/timezone", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"datetime":"2026-07-17T12:00:00Z","from":"UTC"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"datetime":"2026-07-17T12:00:00Z","from":"UTC"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/timezone", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"datetime": "2026-07-17T12:00:00Z",
"from": "UTC"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.timezone",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
This timezone API converts a timestamp between IANA zones using the actual, current daylight-saving rules for each region, so the hour you send is the hour that shows up on the other end.
What POST /dev/timezone actually computes
You send a timestamp along with a source and target zone identifier, such as America/New_York or Asia/Kolkata, and the endpoint returns a task_id while it resolves the conversion asynchronously. It applies the correct offset for that specific date, meaning a July timestamp and a December timestamp for the same city can legitimately convert differently, and it correctly handles the rare edge cases around the DST transition itself, when a clock either skips an hour or repeats one.
The history behind the mess
Daylight saving time was adopted piecemeal by different countries across the twentieth century for energy and agricultural reasons that mostly no longer apply, which is why the rules today are a patchwork rather than a clean global standard. The IANA time zone database, the reference dataset this endpoint relies on, exists specifically to track that patchwork as governments amend it, which is also why it is updated multiple times a year rather than being a fixed, permanent table.
Where automated systems actually need this
Booking platforms use it to show a traveler the correct local arrival time for a flight landing in a different zone, calendar tools use it to keep a recurring meeting anchored to '9am local time' even as DST shifts around it, and logging pipelines use it to normalize timestamps from servers in different regions before analysis. Delivery is via signed webhook, ideal for a scheduling backend reacting in real time, or a signed link valid 24 hours for batch conversion jobs.
Cost and reliability that scale with usage
At $0.002 per request, converting a handful of timestamps or an entire event calendar's worth costs the same predictable rate, and a task that fails is retried up to three times before returning a clear error, never charged if it cannot complete. There is no free trial or tier; prepaid balance is required, which keeps the endpoint responsive under load.
Technical questions
How is this different from just adding or subtracting hours?
A fixed offset ignores daylight saving time, which shifts by an hour twice a year in most regions and follows different schedules by country; this API applies the correct rule for the specific date you send, not a static number.
Is there a free way to try the timezone API?
The tool above runs free in your browser. The API is paid — each call draws from your prepaid ForHosting KIT balance: top up from $10.00 (it never expires), pay each request's published price, and a call with no balance returns HTTP 402. No subscription, no tokens, and a failed task is never charged.
How much does each conversion cost?
Each call to POST /dev/timezone costs $0.002, billed only when the task completes successfully.
Can I convert timestamps in bulk?
Yes. The endpoint is asynchronous and results are delivered by signed webhook or a signed link valid 24 hours, which fits batch jobs converting large timestamp sets without polling.