frontend icon indicating copy to clipboard operation
frontend copied to clipboard

[local calendar]: Adding event to calendar in unknown timezone

Open SkeLLLa opened this issue 2 years ago • 7 comments

Checklist

  • [X] I have updated to the latest available Home Assistant version.
  • [X] I have cleared the cache of my browser.
  • [X] I have tried a different browser to see if it is related to my browser.

Describe the issue you are experiencing

While adding new event to calendar there's no indication in which timezone it will be saved. Local timezone of device? Timezone that configured in HA? UTC?

Describe the behavior you expected

Add clear note about timezone or add timezone selector dropdown.

Steps to reproduce the issue

  1. Set device timezone to different from HA.
  2. Open Local calendar integration.
  3. Add event.
  4. Try to set date/time. ...

What version of Home Assistant Core has the issue?

core-2022.12.1

What was the last working version of Home Assistant Core?

No response

In which browser are you experiencing the issue with?

Home assistant app

Which operating system are you using to run this browser?

Android

State of relevant entities

No response

Problem-relevant frontend configuration

No response

Javascript errors shown in your browser console/inspector

No response

Additional information

No response

SkeLLLa avatar Dec 10 '22 08:12 SkeLLLa

The calendar uses the HA configured timezone. I am not sure if we need to add that to the form or whether that would confuse most users. We are not showing timezones anywhere in the frontend AFAIK (e.g. also not for input_datetime although I think that one technically has no timezone and just stores the values provided by the user).

@allenporter @matthiasdebaat What do you think?

spacegaier avatar Dec 10 '22 10:12 spacegaier

Maybe at least add some text snippet about timezone. Or a hint that below the input will show the time in HA instance timezone.

Naturally users think about time in a timezone they are currently in. Therefore if some user currently situated in a different timezone rather than HA configured, when they add an event from 11:00 to 12:00 and immediately after that go to calendar, they will see different time, e.g. 10:00 till 11:00. And that might be confusing.

SkeLLLa avatar Dec 10 '22 10:12 SkeLLLa

In general as I've learned about calendar systems I believe the work this way:

  • A calendar itself will have data stored in a particular timezone (or it can be floating w/o, but we're not doing that). Home Assistant is definitely using the home assistant timezone for this. (Technically this can be per event event)
  • A viewer or attendee may be in a separate timezone and view the calendar in that timezone. This has an impact on how things like "All day" events are sorted in with events with a specific timezone.

We also want to ensure a viewer has a consistent view of times across the Home Assistant frontend independent of calendar. For example, if you are viewing the Log Book which has a list of events that occurred those would also need to be in sync with the Home Assistant calendar events and timezones. There are some other technical details about how core itself needs a timezone to work in for automations and fetching from calendar APIs like Google Calendar, but i think the general point I'm assuming we'd likely not show different timezones based on the viewers browser.

I think the issue may be that if you enter 11:00 to 12:00 then it should be created at 11:00 to 12:00 in the home assistant timezone, rather than converting from browser time to home assistant time. (You're saying that is what is happening, but i haven't tried it myself, but it makes sense). If that were the case, then i think it wouldn't be surprising and consistent with dates shown across the entire system.

allenporter avatar Dec 10 '22 16:12 allenporter

So I see that with updated core-2022.12.4 the behavior had changed. Now events are added in local browser timezone.

SkeLLLa avatar Dec 13 '22 18:12 SkeLLLa

2022.12.4

That version did not contain any local calendar changes in the frontend. Not sure if something was changed in the backend.

@allenporter Did you adjust something in core?

spacegaier avatar Dec 13 '22 18:12 spacegaier

@spacegaier I've decided to check it once again. And I think it's gone more weird this time. And likely now it's seems connected with https://github.com/home-assistant/frontend/issues/14687 bug.

Before all the steps you need to be sure that timezone of client is set to a different one that's set on HA. In my case HA timezone is GMT+2, client is in GMT+1.

If I click "add even" and leave default values then those values are send to a server with a ws event

{
	"event": {
		"summary": "qwe1",
		"description": "",
		"dtstart": "2022-12-13T23:00:00",
		"dtend": "2022-12-14T00:00:00"
	}
}

In response I receive

{
	"a": {
		"message": "qwe1",
		"start_time": "2022-12-13 23:00:00",
		"end_time": "2022-12-14 00:00:00"
	}
}

Which is displayed in calendar in client's browser as:

December 13, 2022 22:00 - 23:00

When I try to change values the issue #14687 appears. So in UI I'm setting an event time, for example, from 10:00 till 12:00. When I input those values for a first time, after focus change those values in a time picker (on add event form) receive +1, so I see 11:00 and 13:00 instead. Then I change those values once again to 10:00 and 12:00 and on the second time it doesn't add +1. So in UI I see 10:00 and 12:00. However the message that's sent to a backend is

{
	"event": {
		"summary": "qwe2",
		"description": "",
		"dtstart": "2022-12-13T11:00:00",
		"dtend": "2022-12-14T13:00:00"
	}
}

And in response I have the same.

{
	"a": {
		"message": "qwe2",
		"start_time": "2022-12-13 11:00:00",
		"end_time": "2022-12-14 13:00:00"
	}
}

And it's displayed as, which looked like that change of behavior.

December 13, 2022 at 10:00 - December 14, 2022 at 12:00

However, it appeared so just because the changes in time picker was not actually sent to a server as they were in UI.

SkeLLLa avatar Dec 13 '22 22:12 SkeLLLa

Thanks, i think we have enough info, i'll take a look.

allenporter avatar Dec 16 '22 15:12 allenporter