1
00:00:00,080 --> 00:00:03,653
Google Calendar shows the Workshop prep event at the wrong hour.

2
00:00:03,653 --> 00:00:07,226
In this fictional example, it is meant to be nine in

3
00:00:07,226 --> 00:00:10,799
the morning in New York on November twelfth, twenty twenty-six.

4
00:00:10,799 --> 00:00:14,372
That same instant is six in the morning in Los Angeles.

5
00:00:14,372 --> 00:00:17,945
The fix starts by checking two named zones: the calendar display

6
00:00:17,945 --> 00:00:20,219
zone and the event's own zone.

7
00:00:20,819 --> 00:00:24,889
Before changing a setting, record the event's date, intended local time,

8
00:00:24,889 --> 00:00:27,602
and the hour currently shown in the grid.

9
00:00:27,602 --> 00:00:32,011
Use the downloadable no-guest practice sheet so the example cannot notify anyone.

10
00:00:32,011 --> 00:00:36,081
A bare time, such as six o'clock, does not tell us

11
00:00:36,081 --> 00:00:40,490
whether the calendar is wrong; we need the named time zone beside it.

12
00:00:41,090 --> 00:00:44,659
Open Google Calendar Settings and locate the primary time zone.

13
00:00:44,659 --> 00:00:49,656
Read the named zone rather than assuming the computer's clock controls every event.

14
00:00:49,656 --> 00:00:53,582
If this calendar is displayed in Los Angeles, the fictional New

15
00:00:53,582 --> 00:00:57,865
York event appears at six in the morning on the example date.

16
00:00:57,865 --> 00:01:01,791
Changing the primary zone changes the view; it does not by

17
00:01:01,791 --> 00:01:04,289
itself rewrite the event's underlying instant.

18
00:01:04,889 --> 00:01:10,133
Now open the event editor and inspect the event's time and time-zone controls.

19
00:01:10,133 --> 00:01:15,028
The intended record here is nine in the morning in America slash New York.

20
00:01:15,028 --> 00:01:18,873
If the event itself was entered in another zone, changing the

21
00:01:18,873 --> 00:01:21,670
calendar view will only hide the underlying mistake.

22
00:01:21,670 --> 00:01:25,166
Record the event zone before deciding which setting should change.

23
00:01:25,766 --> 00:01:29,565
When the event entry is right and only the calendar view

24
00:01:29,565 --> 00:01:33,019
is in the wrong zone, adjust the primary display zone.

25
00:01:33,019 --> 00:01:37,855
When the event entry is wrong, edit that event's time and zone instead.

26
00:01:37,855 --> 00:01:40,964
Save one intended change, then return to the calendar.

27
00:01:40,964 --> 00:01:44,763
These are different repairs, so avoid changing both at once and

28
00:01:44,763 --> 00:01:47,181
losing track of what solved the mismatch.

29
00:01:47,781 --> 00:01:51,767
For this practice date, the correct comparison is nine a.m.

30
00:01:51,767 --> 00:01:54,665
New York and six a.m. Los Angeles.

31
00:01:54,665 --> 00:01:58,651
Reopen the event details and check that its named zone still

32
00:01:58,651 --> 00:02:00,101
matches the intended entry.

33
00:02:00,101 --> 00:02:03,362
Then compare the grid in the selected primary zone.

34
00:02:03,362 --> 00:02:07,348
This is the expected answer for a date away from a

35
00:02:07,348 --> 00:02:12,421
daylight-saving transition; confirm the actual grid and event details in your own Calendar.

36
00:02:13,021 --> 00:02:16,889
If the hour still seems wrong, inspect a secondary time zone,

37
00:02:16,889 --> 00:02:21,812
another copy of the event, or a date close to a daylight-saving change.

38
00:02:21,812 --> 00:02:26,736
Named zones account for seasonal offsets; a fixed subtraction may fail on other dates.

39
00:02:26,736 --> 00:02:30,956
Do not infer an invited guest's display from your own calendar.

40
00:02:30,956 --> 00:02:35,527
The written guide links the product help and gives the independent arithmetic check.
