Data attribute 'received' element formatted incorrectly

[GitHubGoody]

From what I can tell in this thread, the data attribute's 'received' element is formatted incorrectly.

Here's a sample from one of my query_sensors:
received: 2022-05-20T11:16:07+0000

That's UTC time, but missing the UTC to local offset suffix. In my case, since my time is currently EDT, I think it's supposed to look like this to allow for conversion to local time:
received: 2022-05-20T11:16:07-04:00

I assume that if this were configured properly, the -04:00 would automatically change to -05:00 when daylight savings time ends.

I've confirmed my time zone is properly set in O365.

[RogerSelwyn]

Which attribute of which sensor is this?

[RogerSelwyn]

Oops, you said

[RogerSelwyn]

OK, looked at it further. The date is formatted correctly for what can be provided by the integration because the integration is backend processing, it would need something at the front-end to format the dates for local user time. What you see in Developer Tools is not (in the most part) local timezone aware. I say in the most part, because the start and end time at the root of the calendar entities are formatted by HA at the front end and do show in local time, so do not show +/-xxxx

The +0000 denotes that is UTC.

So a date that says 2022-05-20T11:16:07+0000 is the same as 2022-05-20T12:16:07+0100 or 2022-05-20 12:16:07 in British Summer Time which is GMT+1.

Now of course if you are saying the mail was received at 11:16:07 local time and your are in EDT then it should show 15:16:07+0000, which when you translate to local time would be correct to your eyes. If it doesn't match up like that let me know.

[RogerSelwyn]

Just to add, the backend (where the integration runs), does not know your local timezone so cannot format for it. It may coincidently be that HA is in the same timezone, that cannot be relied on. Any front-end timezone is configured against each user and the backend does not know which user is accessing the data, and therefore what timezone the user is viewing in.

Recently HA has taken the decision that all backend dates will be handled in UTC and only presented in local time by the front-end.

[GitHubGoody]

The message was received at 7:16 AM EDT (11:16 UTC).

I agree those three British Summer Times would be equivalent, but without the offset in the data, I cannot easily account for DST in templates (without changing the offset twice a year)...AFAIK.

Do you know of a way to access the GMT offset in the frontend? If I could use that as a variable, I think I'd be set.

[RogerSelwyn]

I’m afraid not, I’ve not got engaged in HA fronted at all. You could always hard code it, but of course you then need to account for when DST charges for you. There is probably a restapi driven service out there as well that you could pull down the relevant time zone info with a rest sensor, or even one you could push the date/time to that would convert it for you.

[GitHubGoody]

OK, thanks. I guess another reason why having this field included as a query sensor variable would be better since it would be handled on the backend.

[RogerSelwyn]

Please see my comment on your other issue since I need to understand your use case. I’ll close this one.

[GitHubGoody]

Just thinking out loud...

After comparing/contrasting the three example ways to represent the same time at the beginning of this comment, I think something is still off considering:

{{ now() }}

gives me

2022-05-20 12:37:00.029958-04:00

Which is my local time EDT (UTC-4). So, it's providing me with a local time and the UTC offset which is not a combination that post suggests is correct (either the time should be 16:37 or the offset should be dropped). I'll post the question in that post.

[GitHubGoody]

Answer here...just a mistake on his part. The UTC representation is the local time appended with the UTC offset...not the UTC time appended with the UTC offset.

[RogerSelwyn]

Yep, because you are doing that in the front-end, not in the backend. Reality is, I'm not changing how the data is presented, you may process it how you like ;-)

[RogerSelwyn]

Answer here...just a mistake on his part. The UTC representation is the local time appended with the UTC offset...not the UTC time appended with the UTC offset

You are right and wrong. When people say 'UTC' they mean +0000 (i.e. the time at London Greenwich timeline ignoring DST). There are different ways of representing the same time as I showed above, but they all mean the same thing. For HA it has been requested that dates are shown at +0000. You may if you wish translate that to local time in the front-end, since you know how far distant you are from UTC, whilst the backend doesn't.

[GitHubGoody]

Yeah, it's definitely splitting hairs at this point, but his post is about proper formatting, so I was just trying to clarify. I'm with you though...I know what time zone I'm in and can do math ;-)

[RogerSelwyn]

Looking some more (I tend to do that). The requirement from HA is that dates are represented in UTC time zone (which arguably not a thing). To represent in UTC, to be more correct it should be formatted with a ‘Z’ instead of ‘+0000’. However with 1k plus users I’m not inclined to change it when they mean the same thing.

[RogerSelwyn]

https://www.w3.org/TR/NOTE-datetime

[RogerSelwyn]

Looks like you may be able to use this format to present the date in local time in Lovelace.

{{ states.calendar.bookings.attributes.data[0].start|as_timestamp|timestamp_local }}

No idea if you can use that to create a template sensor, but certainly works in templates tab of developer tools.