Time zones when sending Google Sheets rows to Google Calendar

The short answer

If a Google Sheets event appears at the wrong time in Google Calendar, first check File → Settings in the spreadsheet. CalendarRows sends timed events using the spreadsheet’s time zone. A row that says 9:00 AM in a sheet set to New York means 9:00 AM in New York, even if the person sending it works in Los Angeles.

Next, check Settings in Google Calendar and compare the event with the original row. Calendar displays an event to each viewer according to that viewer’s calendar settings. A different displayed clock time can represent the same moment, so identify the zone attached to each time before changing the row.

If the sheet is meant to contain times in one zone, set the spreadsheet to that zone and test one row. If the source times belong to another zone, keep them and calculate separate values for the spreadsheet’s zone. A fixed-hour formula can be enough when you have checked the offset for the event date. It does not adjust itself when clocks change.

CalendarRows is useful when you want to preview rows and maintain their linked events from the sheet. It is not needed just to perform time arithmetic. The free Apps Script in our create-events guide can create events and update basic details without the add-on. For a one-time list, a CSV import may be enough; our import guide covers its limits and a test.

Where the time zones can differ

The spreadsheet. Its time zone tells CalendarRows how to interpret the times it sends. Check File → Settings before preparing the mapping. This setting belongs to the spreadsheet, so agree on what the times in a shared schedule mean before changing it. Write the intended zone in a heading or a note alongside the schedule so that another editor does not have to guess.

The calendar. Check Settings in Google Calendar for the calendar you are examining. The destination calendar and its settings are separate from the spreadsheet setting. CalendarRows attaches the spreadsheet’s zone to a timed event; it does not change your calendar settings. If you also use CSV imports, check the calendar setting for that workflow: the import guide notes that a CSV carries no time zone.

The viewer. A colleague can see the same event according to their own calendar settings. Ask both people to compare the date, clock time and zone shown in their accounts. If the times differ by the expected offset, that can be a normal display of the same moment. If they do not, trace the original row and the sheet setting before deciding which value needs correction.

For example, a meeting intended for 9:00 AM New York time should not be rewritten as 9:00 AM Los Angeles time merely because someone in Los Angeles sees 6:00 AM. Those two clock readings can describe the same meeting. Conversely, if the meeting is intended to start at 9:00 AM in Los Angeles, a sheet set to New York needs a different value or a different zone setting.

We cannot tell from a screenshot of one clock time alone whether a row was entered in the wrong zone, a formula used the wrong offset or a viewer is seeing a correct local display. Check the event date as well as the time, especially for meetings close to midnight.

Example: New York and Los Angeles

Suppose the same event row contains a start date of 2026-11-10 and a start time of 9:00 AM. The table shows what that clock time means when CalendarRows sends it from a spreadsheet set to each zone. It is the same visible row, but the two settings describe different moments.

In this example, New York is three hours ahead of Los Angeles. A 9:00 AM New York event is 6:00 AM in Los Angeles on the same date. A 9:00 AM Los Angeles event is noon in New York. The two events in the table start three hours apart, even though both source rows say 9:00 AM.

Do not assume that a three-hour gap applies to every pair of zones or every date. Daylight saving changes can alter the gap for a few weeks of the year when the places you are comparing change clocks on different dates. Verify the offset for the places and dates in your schedule. For this New York and Los Angeles example, check the relevant dates before using a fixed offset.

To test your own schedule, write down the intended local date and time, the zone in which that time was given and the spreadsheet’s zone. Then compare the event in Calendar with those notes. This gives you a specific expectation to check instead of treating the number in the sheet as meaningful without its zone.

Convert times for a different zone

The simplest arrangement is often to set the spreadsheet’s zone to the zone in which the times are written. If all rows describe appointments in New York local time, a spreadsheet set to New York lets you enter those local times directly. The viewer in another zone can then check the event using their own Calendar settings.

If the spreadsheet must remain in a different zone, convert the times before mapping them to CalendarRows. Google Sheets has no built-in time zone conversion function. You can add or subtract a known whole-hour offset, but you must establish the correct offset for each date yourself. Fixed offsets do not follow daylight saving changes.

Keep the original start and end values in their own columns. Put the converted start and end beside them, label the zones clearly and map the converted columns when sending. This preserves the source information for checking and makes it easier to correct an offset later. Do not apply a conversion on top of a value that has already been converted.

For a concrete example, let B2 contain the complete New York date and time 2026-11-10 9:00 AM. If the spreadsheet is set to Los Angeles and you have verified a three-hour difference for that date, use =B2-TIME(3,0,0) in the converted start column. The result is 2026-11-10 6:00 AM. Map that result as the start in the Los Angeles sheet.

For the other direction, if B2 holds 2026-11-10 9:00 AM Los Angeles time and the spreadsheet is set to New York, =B2+3/24 gives 2026-11-10 12:00 PM for that verified three-hour difference. A day is represented as 24 hours in this arithmetic, so adding 3/24 adds three hours. Apply the corresponding calculation to the end value too.

Use complete date-time values for these examples, not just clock times. Subtracting three hours from 2026-11-10 1:00 AM gives 2026-11-09 10:00 PM. The earlier date is part of the answer. Check that the converted column displays both the date and the time, and check the mapped start and end dates before sending.

These formulas are examples of whole-hour arithmetic, not a zone database. They do not determine the source zone, find an offset or update the offset when daylight saving begins or ends. Around clock changes, check the dates individually. If you cannot establish the correct offset, retain the original values and resolve that question before creating the events.

Choose a layout for a multi-zone team

For a team working with several local schedules, one spreadsheet per zone can make the meaning of each row easier to see. Set each spreadsheet’s zone to the zone of the times entered there. A New York schedule can contain New York clock times, while a Los Angeles schedule contains Los Angeles clock times. Put the zone in the spreadsheet or column heading and test a row from each spreadsheet.

This arrangement reduces the number of manual offsets, but it also means maintaining separate schedules. Decide which spreadsheet is the source for each event and who will update it. If the same event is listed in more than one place, check which row is meant to be sent so that separate entries do not become unwanted separate events.

Another option is one spreadsheet with the original date-time, an offset in hours and a converted date-time for each row. The spreadsheet still has one time zone. The offset describes how to move that row’s source time into that spreadsheet zone; it is not a setting CalendarRows reads as a time zone.

For example, put an original complete date-time in B2, a signed offset in hours in C2, and =B2+C2/24 in the converted column. If the spreadsheet is set to Los Angeles, B2 is 2026-11-10 9:00 AM New York time and C2 is -3, the result is 2026-11-10 6:00 AM. With a positive offset, the formula adds hours instead.

Label the offset direction, such as “hours to add to reach sheet zone”. Record the source zone beside the original time, and check the offset against the event date. Use the same approach for the end, with its own date-time and a verified offset. Map the converted values, not the source values, to the CalendarRows start and end fields.

One offset column is convenient only if the person maintaining it can verify each row. It does not identify a zone or handle a clock change automatically. For a long schedule spanning different clock-change dates, separate sheets or a review of the affected rows may be easier to maintain. If an event crosses a clock change, verify the start and end independently rather than assuming their offsets match.

Overnight and all-day events

An overnight timed event needs an end date as well as an end time. In CalendarRows, if only an End time is supplied, it uses the start date. When the end time is earlier than or equal to the start time, enter the next day as End date. Otherwise the row shows End is not after the start.

For example, a shift beginning at 10:00 PM on 2026-11-10 and ending at 6:00 AM needs an End date of 2026-11-11. If you convert the shift to the spreadsheet’s zone, calculate both complete date-times and inspect the resulting dates. Depending on the offset, a converted start or end can fall on a different calendar day from the original.

If a timed row has no end time, CalendarRows uses the default length selected in the sidebar. The available default is 30 minutes to eight hours, with one hour as the default. For a shift with a known end, enter and map the end instead of relying on that default. Check the event after sending to make sure both ends match the intended schedule.

All-day rows carry dates only, so do not apply an hourly conversion to them. A row with a date and no time anywhere becomes all-day unless an All day column is mapped. When that column is mapped, its value decides whether the row is all-day; it accepts TRUE/FALSE, yes/no or a checkbox.

For an all-day event, CalendarRows treats End date as the inclusive last day. A start of 2026-12-30 and end of 2027-01-01 covers December 30, December 31 and January 1. Leave End date blank for one day. If End date is before Start date, the row reports End date is before the start date. Check those dates separately from any timed rows in the same schedule.

Check a row before sending

Use a small test before sending a full schedule. Choose a row whose intended start and end are known, including the source zone and date. A row near a clock change or midnight deserves its own test because a fixed offset or an unnoticed date change can produce a different result from a midday example.

1. Check File → Settings in the spreadsheet. Confirm that the mapped date and time values are written for that zone, or that your converted columns use an offset verified for the event date.
2. Open Extensions → CalendarRows → Open CalendarRows. On To Calendar, choose the sheet, header row and intended calendar. Check the suggested column mappings, including Start date, Start time, End date, End time and All day where you use them.
3. Choose the test row using Selected rows and click Preview. Review the create, update, delete and unchanged counts and any row problems. Preview does not change the calendar.
4. Send the test row, read its status and open the event in Google Calendar. Check the displayed start and end dates and times against the intended moment. Check Settings in Google Calendar when interpreting the display.
5. Correct the source or converted values if needed, preview the correction and send again. Once the test is right, select the remaining rows, review the new preview and send the schedule.

Preview is a count and problem check; the comparison in Calendar is still necessary to verify the time you intended. Keep the CalendarRows event ID and status columns and their notes with the row. They let CalendarRows match the row to its event when you edit and send it again. Choose the same calendar for that update: sending to another calendar creates a new event there and does not move or remove the original.

CalendarRows Free allows 50 calendar changes per day, counting each create, update or delete. Previews and unchanged rows do not use changes. Pro allows 2,000 changes per day, subject to fair use; see pricing for the plans. A test event and a later correction each count as a change if sent. For a short task, the free allowance or the free script may be sufficient.

Common problems

The event is an hour off. Check the spreadsheet zone, the intended source zone and the event date. If you used a fixed offset, verify it for that date, particularly around clock changes. Also check Settings in Google Calendar and compare the event as the viewer sees it. An hour’s difference is a clue, not proof of a particular cause.

The event is off by several hours. Check whether the row was entered as a local time for one place while the spreadsheet is set to another. Confirm which columns CalendarRows mapped, especially if both original and converted times are present. Compare both times with their zone labels before changing anything.

The date changed after conversion. Adding or subtracting hours can cross midnight. Inspect the complete converted date-time, not only its displayed clock time. Check the end as well as the start and map the converted dates. If a time-only cell hides the date you need, use a complete date-time value for the calculation and verify the result.

The status mentions 9:00 AM. A timed row without a start time can be sent with the note No start time given; used 9:00 AM. Check whether Start time is mapped to the intended column and whether the row has a readable time. Check the All day value if the row was meant to carry dates only. Correct the row and send it again to the same calendar.

An imported tab has unexpected times. CalendarRows imports events into a new tab. Compare a sample imported row with its event and check the spreadsheet zone and Calendar settings before editing or sending it back. We cannot determine the cause from the displayed time alone. On the first send of an imported tab to the same calendar, every row with an event counts as an update because the imported rows do not yet have fingerprints.

The end is not after the start. Check the start and end dates after any conversion. For an overnight event, supply the next day as End date when the end clock time is earlier than or equal to the start. Correct the row and preview again. If the status reports a different error, read its reason and consult the CalendarRows documentation.

The event is correct for one viewer but surprising to another. Compare the date, time and zone in each viewer’s Calendar settings. The viewers may be seeing the same moment in different local times. Agree on the intended moment before changing the source row, then verify it with both viewers.

Frequently asked questions

Related

• Create Google Calendar events from Google Sheets
• Import a spreadsheet or CSV into Google Calendar
• Put a shift schedule in Google Calendar
• Update Google Calendar events from Google Sheets
• CalendarRows documentation
• All guides

Disclosure: we make CalendarRows, the Google Sheets add-on mentioned in this guide. The basic Apps Script in our create-events guide can create events and update basic details without the add-on.

Google Sheets, Google Calendar and Google Workspace are trademarks of Google LLC. CalendarRows and Cellbrook are not affiliated with or endorsed by Google.