Meetin.gs stores a city-based zone such as Europe/Helsinki and shows every guest their own local time. Offsets and abbreviations break at daylight-saving changes; city zones do not. The time zone guide explains the traps.
Before you start
- Your base zone as a city name.
- The next daylight-saving transition date on both sides.
- One guest in another zone to test with.
How to complete this task
- Set the organizer's base zone using a city-based IANA identifier.
- Compare the same slot in the organizer and invitee zones.
- Test dates on both sides of the next daylight-saving transition.
- Write the zone beside any time repeated outside the scheduling page.
Finish by opening the public link in a signed-out browser: a saved setting is not proof that the guest path works.
Troubleshooting
The problems people report most often with this task, and the cause behind each one.
The invitee saw a time an hour off.
This is nearly always a daylight-saving boundary. Test a date on each side of the next transition before publishing recurring times.
Which time zone does the poll use?
The organizer's stated zone, for every viewer. Restate it in the meeting title whenever participants are in different regions.
A city abbreviation caused confusion.
Use full IANA identifiers such as Europe/Helsinki rather than CET or EST. Abbreviations are ambiguous and change with the season.
Related Meetin.gs help
Return to the Meetin.gs Help Center for the adjacent configuration guide, or send the exact event code and expected result when the documented checks do not explain the behavior.
