Goal
Convert a date and time between two fixed UTC offsets without pretending to know city daylight-saving rules.
Time Zone Offset Converter
Convert a date and time between two fixed UTC offsets without pretending to know city daylight-saving rules.
Key facts
- What it does
- Convert a date and time between two fixed UTC offsets without pretending to know city daylight-saving rules.
- Formula
Convert source local time to UTC by subtracting its offset, then add the target offset.- You enter
- Source date · Source time · Source UTC offset · Target UTC offset
- Worked example
- 12:00 UTC converts to 17:30 at UTC+5.5 on the same date.
A clearer path to an answer
From your question to a useful result
This page keeps the calculation transparent: define the goal, enter the matching values, inspect the method, and decide what the result means in your situation.
Inputs
Source date · Source time · Source UTC offset · Target UTC offset
Method
Convert source local time to UTC by subtracting its offset, then add the target offset.
Next step
Calculate, review the assumptions below, then compare a related tool when the decision needs more context.
Time Zone Offset Converter
Convert a date and time between two fixed UTC offsets without pretending to know city daylight-saving rules.
Open the Time Zone Offset Converter pageMore date-time tools
Download PDFDownload Word (.doc)
Result
Enter your values above and choose Calculate to see the result here.
Calculation map
Follow the path from input to answer
01
Inputs (4)
- Source date Ready
- Source time Ready
- Source UTC offset Ready
- Target UTC offset Ready
02
Formula
Convert source local time to UTC by subtracting its offset, then add the target offset.
Bounded, transparent calculation
03
Result
- Calculate to preview the result.
Recent runs
Your recent runs stay in this browser session only.
Formula, assumptions, and example
Formula: Convert source local time to UTC by subtracting its offset, then add the target offset.
Fixed offsets are useful for transparent arithmetic, while city/time-zone databases require changing daylight-saving and historical rules.
- Offsets are fixed numeric UTC offsets for the entered date.
- City names, DST transitions, historical rules, and future rule changes are not inferred.
Worked example: 12:00 UTC converts to 17:30 at UTC+5.5 on the same date.
Displayed input contract
- Source date
- Source time
- Source UTC offset · minimum -12 · maximum 14
- Target UTC offset · minimum -12 · maximum 14
The displayed limits are checked before the handler runs. Model-specific domain checks may also reject impossible or non-finite inputs.
Methodology: This calculator follows the WorldCalculate input, formula, precision, and boundary policy. Read the official methodology.
Calculator usage statistics
Usage of this calculator and related tools
This section counts anonymous successful Calculate submissions, not unique visitors. Counts and top tools appear only when trusted aggregate data is available; country analysis is shown only under the same condition and reporting threshold.
Total successful calculations
Top tools
Country analysis
Most-used tools
Where usage is reported
Answer-first guide
How to use the Time Zone Offset Converter for a real question
Convert a date and time between two fixed UTC offsets without pretending to know city daylight-saving rules. Start with one clearly defined goal, enter values in the units shown, and keep the result attached to the assumptions below.
What this answers
This tool is useful when your question includes time zone calculator, UTC offset, time conversion. It returns the outputs declared in the calculator contract rather than a live quote, approval, diagnosis, or professional sign-off.
What you enter
Source date · Source time · Source UTC offset · Target UTC offset. Keep the same time period, unit system, and currency wherever the form requires comparable values.
How to check it
Run the worked example first, compare its output with the page's example, then change one input at a time. This makes an unexpected result easier to trace to a unit, boundary, or assumption.
Three checks before you rely on the answer
- Match the question. Confirm that the result means the quantity you need, not a similar-sounding percentage, balance, rate, or estimate.
- Match the inputs. Use the requested units and period, and read each hint before replacing the example values with your own.
- Read the boundary. Review the assumptions and limits. Offsets are fixed numeric UTC offsets for the entered date.
Need a wider view? Browse Date & Time Calculators or compare the related tools below. The WorldCalculate methodology explains how formulas, examples, limits, and revisions are reviewed.
How to use the Time Zone Offset Converter
- Enter Source date.
- Enter Source time — Use 24-hour HH:MM.
- Enter Source UTC offset (hours).
- Enter Target UTC offset (hours).
- Choose Calculate and read the result panel.
- Use Download PDF or Download Word to save a result sheet.
Formula
Convert source local time to UTC by subtracting its offset, then add the target offset.
Fixed offsets are useful for transparent arithmetic, while city/time-zone databases require changing daylight-saving and historical rules.
Worked example
12:00 UTC converts to 17:30 at UTC+5.5 on the same date.
Assumptions and limits
- Offsets are fixed numeric UTC offsets for the entered date.
- City names, DST transitions, historical rules, and future rule changes are not inferred.
Context and background
The calendar conventions behind the answer
Date and time results depend on endpoints, elapsed versus inclusive counting, weekends, supplied holidays, and whether time zones are included.
Calendar arithmetic translates dates and clock readings into durations and schedules. It is separate from local operating policy or a live calendar service, so the page states what it does and does not count.
Research and review
How this guide was researched
Researched by Hassan ALRowaie, Founder and editorial researcher at WorldCalculate.
This guide follows the live calculator's declared inputs, formula, worked example, assumptions, validation boundaries, and source-backed methodology. The review date describes editorial review of the calculator explanation; it is not a promise that external facts or rates remain current.
This time-zone tool performs one transparent conversion between two numeric UTC offsets. You state a source date, a source clock time, the source offset, and the target offset; the handler subtracts the source offset to obtain UTC and then adds the target offset. It returns a target date and time plus the numeric offset difference. The calculation is intentionally not a named-zone lookup. It does not identify a city, select a daylight-saving rule, reconstruct historical changes, or predict a future rule change. That distinction matters because a label such as a city name can correspond to different offsets on different dates, while a fixed number is unambiguous for the one scenario entered here. The page validates a YYYY-MM-DD Gregorian date, an exact 24-hour HH: MM time, and finite offsets from -12 through +14 hours. It handles midnight, month, year, and leap-day rollover through UTC date arithmetic. This guide explains the field contract, the formula, fractional offsets, worked forward and backward shifts, validation, display precision, and the limits of using fixed arithmetic where a named-zone history is required.
The page converts offsets, not places
The title says time-zone offset converter, but the actual input contract is narrower than a city-aware time-zone service. The page asks for Source UTC offset and Target UTC offset as numbers in hours. It never asks for a country, city, named zone, or daylight-saving preference. A conversion therefore means: for this stated date and clock reading, interpret the source clock as having the first numeric offset, then express the same instant using the second numeric offset.
A fixed offset is a useful abstraction when the offset is already known. It can represent a meeting note that explicitly states UTC+5.5, a system log whose offset is embedded in the record, or a controlled exercise about adding and subtracting UTC differences. The number makes the assumption visible instead of hiding it behind a place name. If the source value is a city label without a verified offset for the entered date, this page does not have enough information to choose the correct number.
The same distinction prevents an easy overclaim. A result such as 17:30 at UTC+5.5 means the arithmetic used +5.5 for the target scenario. It does not mean that every location commonly associated with that offset was at that offset on every date, nor that a target city has been identified. Treat the offset values as facts supplied for one conversion, and keep their source or operational meaning in the surrounding record when the result matters.
- The source and target are numeric UTC offsets, not city names.
- The calculation describes one stated date and time.
- A fixed offset is useful when the applicable number is already known.
- The result does not identify a place or choose a time-zone rule.
Enter a valid source date
The Source date field uses the exact YYYY-MM-DD shape. The handler requires four digits for the year, two for the month, and two for the day, with hyphens in the expected positions. It then checks that the components form a valid Gregorian date. The accepted source year is from 0001 through 9999 inclusive. A date that merely looks well formed, such as 2026-02-31, is rejected because its calendar components do not describe a real date under the handler's check.
Month lengths and leap-day rules are therefore part of the input validation even though the form has only one date field. January 31 is valid, April 31 is not, and February 29 depends on the entered year. Do not repair an invalid date by silently moving it into the next month before calculating. Correct the source date first so that the conversion remains tied to the date the user intended.
The date is interpreted at UTC midnight before the source clock minutes and offset are applied. That internal choice keeps the result independent of the computer's local time zone. It does not make the date a UTC date in the user's original wording; it is the calendar date attached to the source local time, represented in a UTC-based calculation so the offset shift is explicit.
- Use exactly four-digit year, two-digit month, and two-digit day fields.
- The source date must be a valid Gregorian date from 0001 through 9999.
- Invalid month lengths and invalid leap days are rejected.
- The internal date arithmetic uses UTC to avoid local-machine time-zone drift.
Enter the source clock time
The Source time field accepts a five-character 24-hour value in HH: MM form. Hours must be from 00 through 23, and minutes must be from 00 through 59. The handler applies this regular structure directly, so a value such as 7:30 is not the same input as 07:30. The page also does not accept seconds because the field contract contains no seconds component.
The time check is stricter than a general-purpose text cleanup. The handler limits the field to five characters and tests the submitted string as written; it does not trim the value before the regular-expression check. Leading or trailing spaces therefore make an otherwise familiar time invalid. Enter the clock reading without a label, time-zone suffix, or explanatory text. The offset belongs in its own numeric field.
Midnight is a normal valid value, not a missing time. 00:00 is useful when testing date rollover because even a small negative shift can move the result to the previous date. Likewise, 23:59 is valid and can move forward after adding a target offset. The conversion never treats 24:00 as a special end-of-day spelling; use the next date with 00:00 if that is the intended instant.
- Use exact 24-hour HH: MM syntax, including leading zeroes.
- Hours 00-23 and minutes 00-59 are accepted.
- Seconds, time-zone suffixes, labels, and surrounding spaces are not accepted.
- 00:00 and 23:59 are ordinary valid boundary times.
The two offset fields
Source UTC offset tells the handler how far the source clock is ahead of or behind UTC. Target UTC offset supplies the corresponding number for the target representation. Both fields accept finite numeric values between -12 and +14 hours inclusive. Zero means UTC. A positive value is added when expressing an instant in that offset, while a negative value moves the displayed clock behind UTC.
The fields use step any, so the contract does not restrict entries to whole hours or a preselected list of common offsets. The default target value 5.5 represents five and one-half hours, and the calculator can also process other decimal values within the range. That flexibility is useful when a fixed offset is known, but it places responsibility on the user to enter a meaningful number and to understand its precision.
The numeric validation rejects text, NaN-like values, infinity, and numbers outside the stated range. It does not validate a place-specific claim about the number. An offset of +5.5 is accepted because it is a finite value in range, not because the page has looked up a named location. Record the meaning of an unusual decimal offset outside the form if another person will need to review the conversion.
- Source and target offsets are finite numbers from -12 through +14 hours.
- UTC is represented by numeric offset 0.
- Decimal offsets such as +5.5 are allowed; the field is not a fixed option list.
- Range validation does not verify that an offset belongs to a particular place.
Convert through UTC
The core formula has two stages. First, UTC time = source local time - source offset. Second, target local time = UTC time + target offset. In minute form, the handler starts with the source date at midnight, adds the entered hour and minute, subtracts fromOffset x 60 minutes, and then adds toOffset x 60 minutes. The date object carries any movement across midnight into the appropriate neighboring date.
The combined clock shift can be written as target local time = source local time + (target offset - source offset). The two-stage UTC wording is still valuable because it shows why the source offset is subtracted and the target offset is added. A positive difference makes the target clock later for the same instant; a negative difference makes it earlier. The result is not an elapsed duration from one event to another.
The handler formats the resulting date with UTC calendar getters and returns the target as YYYY-MM-DD HH: MM. This means the machine's own regional settings do not change the answer. The calculation is deterministic for the four submitted fields, aside from the ordinary precision consequence of entering decimal hour offsets that do not correspond to an exact minute.
- First subtract the source offset to obtain UTC.
- Then add the target offset to express the same instant.
- The net shift is target offset minus source offset.
- Output formatting uses the calculated UTC date and clock components.
The default example step by step
The default scenario uses source date 2026-01-15, source time 12:00, source offset 0, and target offset +5.5. Because the source offset is zero, the source local reading is already the UTC reading for this scenario. Adding five and one-half hours to 12:00 gives 17:30. The target date stays 2026-01-15 because the shifted clock remains before midnight.
The first result is the text Target local date and time, which is 2026-01-15 17:30. The second result is Offset difference, equal to 5.5 hours. The two values answer different questions: the first is the converted calendar reading, while the second exposes the arithmetic shift used to get there. Keep both when explaining why the target time changed.
A quick hand check is to split the half hour from the whole hours. Twelve hours plus five hours is 17:00, and adding the remaining half hour gives 17:30. For a source offset of zero this check is especially direct. In a nonzero source scenario, first form the UTC reading, then apply the target offset rather than adding the target number to the source clock without accounting for the source number.
- Source: 2026-01-15 12:00 at UTC+0.
- UTC stage: 12:00 because the source offset is zero.
- Target stage: 12:00 + 5.5 hours = 17:30.
- The target remains on 2026-01-15 and the offset difference is +5.5 hours.
Forward rollover into the next date
Suppose the source is 2026-01-15 23:40 at UTC-5 and the target offset is UTC+9.5. The source reading is five hours behind UTC, so subtracting a source offset of -5 is equivalent to adding five hours. The UTC stage is 2026-01-16 04:40. Adding nine and one-half hours gives 2026-01-16 14:10. The target date is one day later even though the source date was January 15.
This is not an error caused by a long list of dates. It is the ordinary consequence of representing one instant on a clock that is far ahead of the source clock. The date belongs with the time in the output; copying only 14:10 would lose the fact that the target falls on January 16. When scheduling a meeting or comparing records, carry the full target date and time rather than adjusting the date mentally after the conversion.
The same pattern can cross a month or a year. A late reading on the last day of a month can become an early reading on the first day of the next month. The handler uses calendar-aware UTC date arithmetic, so it does not assume every month has the same number of days. The input date remains the stated source date; only the converted target representation rolls forward.
- A negative source offset is subtracted, which moves the UTC stage later.
- 2026-01-15 23:40 at UTC-5 becomes 2026-01-16 04:40 UTC.
- Adding UTC+9.5 gives 2026-01-16 14:10.
- Always keep the target date attached to a time that crosses midnight.
Backward rollover into the previous date
A target can also move backward. Use source 2026-01-15 01:15 at UTC+5.5 and target UTC-8. Subtracting 5.5 hours from the source clock produces 2026-01-14 19:45 UTC. Adding -8 hours produces 2026-01-14 11:45 at the target offset. The target date is the previous calendar day because the source time was close to midnight and the target offset is substantially farther behind UTC.
The date rollover is tied to the instant, not to the sign of one field by itself. A negative target offset often makes a clock earlier, but a conversion from another negative offset may still move forward if the target is less negative. Compute the net difference or use the explicit UTC stages rather than relying on a phrase such as ahead or behind without numbers.
Backward rollover is important for records near a reporting boundary. A source event logged just after local midnight may belong to the previous target date. If a later system groups records by date, use the converted target date returned by the calculator and document that grouping rule. This page performs the arithmetic; it does not decide which business date, billing day, or reporting period an organization should assign.
- Positive source offsets are subtracted before the target offset is added.
- 2026-01-15 01:15 at UTC+5.5 becomes 2026-01-14 19:45 UTC.
- Adding UTC-8 gives 2026-01-14 11:45.
- A converted date can precede the source date even when the input date is valid.
Read the offset difference result
The second output is Offset difference, calculated as toOffset - fromOffset. If the source is UTC-5 and the target is UTC+9.5, the difference is 14.5 hours, so the target clock is 14 hours and 30 minutes later for the same instant. If the source is UTC+9 and the target is UTC-4, the difference is -13 hours, so the target clock is 13 hours earlier. The sign is meaningful and should remain attached to the number.
The difference is not a second date conversion and it is not the duration between two events. It describes the relative offset positions used by the formula. Two timestamps with different dates can represent the same instant after conversion; the fact that the displayed dates differ does not mean the event lasted a day. Conversely, two identical clock readings can refer to different instants if their offsets differ and their dates are not interpreted together.
The result is displayed with a numeric precision of two decimal places. The underlying inputs can contain more decimal detail because both offset fields accept step-any numbers, but the visible result is a formatted value. Use the submitted offsets and the full target result when a later calculation depends on more precision than the displayed difference conveys.
- Offset difference = target offset - source offset.
- Positive means the target clock is later for the same instant.
- Negative means the target clock is earlier for the same instant.
- It is a relative offset, not an elapsed event duration.
Decimal offsets and minute display
The default +5.5 offset is exactly five hours and thirty minutes, so it maps neatly onto the HH: MM output. Other decimals can describe other fixed shifts. For example, 5.75 hours is five hours and forty-five minutes. If a source time is 12:00 at UTC+5.75 and the target is UTC+0, the target reading is 06:15 on the same date. The calculator does not require offsets to be whole hours or half hours.
Because the fields accept any finite number in range, a user can enter a decimal that represents a fraction of a minute. The internal date calculation multiplies the hour value by 60 minutes, while the returned target clock includes only hours and whole minutes. Seconds or milliseconds created by a sub-minute fraction are not included in the displayed string. Do not treat an HH: MM result as a complete seconds-accurate timestamp for such an input.
The safest practice is to use an offset expressed in a precision that matches the intended clock record. If the known offset is in quarter-hour or half-hour increments, enter that exact decimal and check the resulting minutes. If a source supplies greater precision, preserve that source detail in external notes and decide whether this page's minute-only output is sufficient before using the result operationally.
- 5.5 hours means five hours and thirty minutes.
- 5.75 hours means five hours and forty-five minutes.
- Sub-minute decimal offsets can create seconds that the HH: MM output omits.
- Match offset precision to the precision required by the surrounding timestamp record.
Month ends, leap days, and year edges
Date rollover must respect the actual calendar. Moving forward from the end of a 30-day month does not create a nonexistent day 31, and moving backward from the first of a month reaches the last valid day of the previous month. February requires the same care: a valid leap-day input can roll into March, while an invalid February 29 input is rejected before any offset arithmetic begins.
The parser accepts the source date only when its year, month, and day survive the UTC calendar check. The shift then uses the date object's UTC representation, which carries hours across month and year boundaries. This is why a one-line offset formula still needs a date-aware implementation. Adding 26 hours to a clock reading cannot be completed by changing the hour text alone; the calendar date must be advanced as well.
At the edges of the accepted source-year range, remember that validation is applied to the submitted source date. The target is generated after the offset shift, so a result near a year boundary should be read from the returned target text rather than assumed to have the same four-digit year as the input. The page does not attach a separate business-calendar or reporting-period interpretation to that returned date.
- Calendar rollover uses the actual month lengths handled by UTC date arithmetic.
- Leap-day validity is checked on the source date.
- Adding or subtracting hours can change month or year as well as day.
- Read the returned target date instead of copying the source year forward.
Validation errors are part of the contract
A source date with the wrong shape or an impossible calendar day is rejected with a date-specific validation message. A source time with missing leading zeroes, an invalid hour, an invalid minute, extra spaces, seconds, or a suffix is rejected by the HH: MM check. The numeric fields reject nonfinite values and numbers outside -12 through +14. These checks keep a failed input visible instead of producing a plausible-looking but ambiguous timestamp.
The handler does not infer missing information. It will not turn 12 into 12:00, choose UTC when a source offset is omitted, read a sign from a city label, or correct an offset that was entered in minutes rather than hours. The field labels are the unit contract: offsets are hours, and the time text is a 24-hour clock reading. If the source record uses another convention, normalize it deliberately before submitting the four fields.
An exact selector is not involved in this calculator, so there is no operation choice to fall back to. The output always describes the one conversion defined by the entered source date, source time, and two offsets. If a result looks unexpectedly far away, recheck the signs first, then check whether the source and target offsets were accidentally swapped.
- Correct the source date instead of letting an invalid day roll into another month.
- Enter offsets in hours, not minutes, and include their signs.
- Do not expect missing time components or suffixes to be inferred.
- If the shift looks backward, verify that source and target offsets were not swapped.
Daylight saving is deliberately absent
A named time zone can use one offset during part of a year and another offset during a daylight-saving period. A historical record can also use rules that differ from today's rules, and a future date can be affected by a rule change that is not known when the record is created. This calculator does not contain those transitions. It applies the exact numeric offsets supplied for the entered date without checking whether a named region would have used them.
This boundary is different from saying that daylight saving never matters. It says that daylight-saving logic must be resolved before this page is used when the source or target is a place whose offset changes. A user who already has the correct effective offsets for the date can use the page for the final arithmetic. A user with only two city names cannot obtain a reliable place conversion from this four-field contract.
Do not add a daylight-saving hour after the result unless the method you are following explicitly requires it and identifies which side of the conversion it applies to. Manually adding a correction can double-count a transition or apply it to the wrong date. Keep named-zone resolution and fixed-offset arithmetic as separate steps so each assumption can be reviewed.
- No daylight-saving transitions are looked up or inferred.
- Historical and future named-zone rule changes are outside the handler.
- Resolve effective offsets separately when a place has changing rules.
- Do not apply an extra daylight-saving correction without an explicit rule and date.
Useful fixed-offset scenarios
The calculator is well suited to a record that already states its offsets. A technical log might say that an event was recorded on 2026-03-01 at 18:20 with a -4-hour offset, and a receiving system might need the corresponding reading at +1. Entering those four facts gives a deterministic target date and time without pretending that the page knows which place produced the log. The result can then be compared with a system record that uses the same fixed conventions.
It can also support teaching and review. Students can test why subtracting the source offset is necessary, explore a half-hour target, and observe date rollover at midnight. A reviewer can reproduce a conversion from a written incident timeline by recording the date, HH: MM value, source number, target number, and displayed difference. The small field set makes a sign error easier to isolate than in a hidden place-name lookup.
For recurring appointments, the one-time calculation should not be copied blindly across a whole season if either named location can change offset. Recalculate each date after the effective fixed offsets are known, or use a named-zone system for the rule resolution and use this page only as an arithmetic cross-check. The calculator reports a conversion, not a calendar invitation policy or an attendance guarantee.
- Use it when both effective numeric offsets are already stated.
- Keep the source date, exact time, signs, and target result together in records.
- Use rollover examples to test sign and calendar understanding.
- Re-evaluate recurring events when an effective offset can change.
What the output does not promise
The Target local date and time is the result of the entered arithmetic. It is not a proof that a local clock in a named region displayed that value, because no region or rule database was supplied. It also does not prove that the source timestamp was recorded correctly, that the two offsets were authoritative, or that the event belongs to a particular accounting or reporting date.
The page does not calculate an elapsed duration, compare two independent events, handle ambiguous or repeated local times during a transition, or provide a list of all places sharing an offset. It accepts one source date and time, not a start and end interval. It has no fields for seconds, calendar-system selection, leap seconds, location, historical version, or rule provenance. Those omissions are intentional scope boundaries rather than hidden defaults.
If a decision depends on legal deadlines, financial cutoffs, distributed-system ordering, or a named location's historical record, use the governing time standard and a qualified implementation for that task. This page can remain a transparent arithmetic check when the effective offsets are explicit. Preserve the raw inputs and the returned text so another person can distinguish the calculation from the larger timekeeping decision.
- The target text is an arithmetic result, not named-zone evidence.
- No duration, location list, seconds field, or transition ambiguity is calculated.
- The source offsets and timestamp quality are not independently verified.
- High-consequence deadlines need the applicable timekeeping authority and method.
A precise conversion checklist
Write the source date in YYYY-MM-DD form and confirm that the day exists in that year. Enter the clock as exactly HH: MM in 24-hour notation, without seconds or spaces. Then state the source and target offsets in hours, including the signs. If either number came from a named location, resolve and record that fact separately; this page assumes the numbers are already the correct fixed offsets for the stated date.
Apply the two-stage check: source local minus source offset gives UTC, then UTC plus target offset gives the target reading. If the target crosses midnight, carry the new date through the month or year boundary. Compare the displayed Offset difference with target minus source. For a decimal offset, check whether the chosen precision maps cleanly to whole minutes because the returned clock shows HH: MM only.
Finally, label the result as a fixed-offset conversion rather than a named-zone prediction. Keep the four inputs, the target date and time, and the offset difference in any note or report. The page is reliable for the arithmetic it defines and intentionally silent about DST, historical rules, future changes, locations, and broader scheduling policy. That narrowness is what makes the calculation inspectable.
- Validate the Gregorian source date and exact HH: MM source time.
- Enter both fixed offsets in hours with the correct signs.
- Check UTC staging, date rollover, and target minus source difference.
- Label the result as fixed numeric-offset arithmetic, not named-zone resolution.
Frequently asked questions
What is the Time Zone Offset Converter?
Convert a date and time between two fixed UTC offsets without pretending to know city daylight-saving rules.
What is the formula for the Time Zone Offset Converter?
Convert source local time to UTC by subtracting its offset, then add the target offset. Fixed offsets are useful for transparent arithmetic, while city/time-zone databases require changing daylight-saving and historical rules.
What do I need to use this calculator?
Enter Source date, Source time, Source UTC offset, Target UTC offset, then choose Calculate.
What are the limits of this calculator?
Offsets are fixed numeric UTC offsets for the entered date. City names, DST transitions, historical rules, and future rule changes are not inferred.
Methodology
This calculator is part of the WorldCalculate library. Its formula, example, assumptions, input bounds, and output formatting follow the official methodology.
Use this calculator as part of a bigger plan
These WorldCalculate collections connect this tool with related questions while keeping each calculation separate and transparent.