How do I convert a meeting time between timezones correctly?
Choose the local wall-clock date and time, its source IANA timezone and the destination timezone. Dhrub Free Tools uses Day.js with the browser’s Internationalization API to resolve the source instant and apply each zone’s offset for that date, including known daylight-saving rules. A timezone name such as Asia/Kathmandu is safer than an abbreviation such as CST, but future government changes and repeated clock times still require confirmation.
How to use the tool
Choose the date task
Select age and difference, Unix time, or meeting zones.
Enter the value and its context
Supply both calendar dates, identify seconds versus milliseconds, or choose the source and target IANA zones.
Read and verify the result
Copy the ISO or Unix value, or confirm both meeting displays and UTC offsets with participants.
At a glance
- Calendar difference
- Completed years, months and days plus total days
- Unix units
- Seconds and milliseconds
- Timezone identifiers
- IANA names such as Asia/Kathmandu
- Timezone engine
- Day.js using the browser Intl API
- Server required
- No
Calendar age is not elapsed milliseconds divided by 365 days
Calendar years and months have unequal lengths. The age calculator advances through valid calendar anniversaries, then complete months, then remaining days. It also shows complete elapsed days using date-only UTC boundaries so daylight-saving transitions do not turn a civil day into a fractional result.
A 29 February start needs an explicit policy in a non-leap year. This tool uses the last valid day of February for completed-year arithmetic. That is a transparent calculation convention, not a ruling on legal age, benefit eligibility, contract deadlines or an authority’s filing rules.
- Use date-only mode for birthdays and calendar intervals.
- Use Unix mode for a machine timestamp tied to one instant.
- Keep seconds and milliseconds explicit; confusing them changes the date dramatically.
- Apply the receiving organisation’s legal or business rule when it differs from the displayed convention.
Offsets depend on the zone and the date
The IANA Time Zone Database records historical and planned UTC-offset rules for named regions and is updated when governments change them. Browsers receive timezone data through their own software updates, so an old browser or operating system may disagree with a newly announced rule.
When clocks move forward, some local times do not exist; the meeting converter rejects a time that cannot round-trip in the source zone. When clocks move backward, one wall-clock time can occur twice. The interface shows the chosen numeric offset, but participants should confirm which occurrence they mean.
Important limitations
- The calendar result is a documented arithmetic convention, not legal advice or an official age determination.
- Timezone accuracy depends on the IANA-derived data shipped by the browser and operating system.
- A repeated local time during a fall-back transition can identify two instants; confirm the intended UTC offset.
- Unix timestamps do not carry a timezone name, calendar, locale or human intent by themselves.
- The meeting list is intentionally curated rather than an exhaustive timezone picker.
Questions people ask
Why does the age result show years, months and days instead of a decimal?
Calendar units vary in length. Completed calendar components communicate the interval more accurately than dividing elapsed days by an average year.
Is my timestamp in seconds or milliseconds?
The value alone may be ambiguous. Unix seconds are commonly about ten digits for current dates, while browser milliseconds are commonly thirteen, but choose the unit from the source specification rather than guessing.
Why can the same local meeting time occur twice?
When daylight saving ends, clocks can repeat an hour with two different UTC offsets. Ask which offset or instant the organiser intends.
Does the converter upload my dates?
No. Calendar, timestamp and timezone calculations run in the browser; no account or server conversion is required.
Primary and project sources
- ECMAScript Date objects — Ecma International / TC39Primary JavaScript specification for Date values and their supported time range.
- ECMAScript Internationalization API — Ecma International / TC39Primary specification for Intl.DateTimeFormat and named timezone handling.
- Time zone and daylight-saving data — Internet Assigned Numbers AuthorityOfficial background on the timezone database and date-dependent government rules.
- Day.js timezone plugin — Day.js projectPrimary documentation for parsing and converting values in named timezones.
- Date and Time on the Internet — RFC Editor / IETFInternet timestamp format, UTC and numeric-offset guidance.