Problem with timestamp sensor following change to summer time

Configuration
1

I have a sensor which stores tomorrow’s sunrise time for further manipulation in other template sensors. Until yesterday, this all worked fine, but following the change to summer time, the template sensor converts the ‘+0100’ time to an ‘actual’ ‘+0000’ time, which creates issues down the line, as I need to keep the ‘+0100’.

The sensor definition is:

name: “Sunrise Tomorrow”
unique_id: sunrise_tomorrow
device_class: timestamp
state: >
{{
as_timestamp(state_attr(‘sensor.home_sun_rising’,‘tomorrow’),0) | timestamp_custom(‘%Y-%m-%dT%H:%M:%S%z’)
}}

In the template editor, when I copy and paste the ‘as_timestamp’ bit, the result is correct as ‘2026-03-30T06:44:14+0100’. However, in the same template editor, when I check states(‘sensor.sunrise_tomorrow’) I get ‘2026-03-30T05:44:14+00:00’.

Is there a way for me to keep the ‘+0100’?

2

Perhaps + timedelta(hours = now().timetuple().tm_isdst)

Or given that you have timestamp.

+ (now().timetuple().tm_isdst * 3600)

Edit… misunderstood.
Thought you wanted the time to be correct.
But replacing the z part of the timestamp doesn’t make sense.
What are you using this for?

3

I am running an app which generates an array of figures like this:
image
What I do is extract the value at sunrise and at sunset from this array. I have a second sensor which rounds the sunrise and sunset times to the nearest five minutes so it matches the date/time entries in the array, at least, that was before the clocks changed :wink:.

4

If you want the time value to be the time for “+0100”, you would use the info from timetuple like Hellis81 showed, then just concatenate the tz value onto the datetime string instead of getting it from the datetime itself.

{% set adj_time = state_attr('sensor.home_sun_rising','tomorrow')
+ timedelta(hours=now().timetuple().tm_isdst) %}
{{ adj_time.strftime('%Y-%m-%dT%H:%M:%S') ~ '+0100'}}

Otherwise, leave the timedelta out and just do the concatenation:

{{ state_attr('sensor.home_sun_rising','tomorrow').strftime('%Y-%m-%dT%H:%M:%S') ~ '+0100'}}
5

Wouldn’t it be easier just to use the sun integration, and to be specific
sensor.sun_next_rising

Sensors Description
Next rising Date and time of the next sun rising (in UTC).
6

I need to use both sunrise and sunset, so it wouldn’t be consistent as we go through the day, i.e. the next sunset could be before the next sunrise.

8

@AberDino and i think you dont need an tamplate sensor, there is an native integration or you can use hacs integration called astroweather

9

Thanks @Didgeridrew, but even when I use your “timetuple” code, the states(‘sensor.sunrise_tomorrow’) still returns ‘+0000’. My issue is that the array I’m extracting data from, uses ‘+0100’ since the clocks changed, so what I feed into it to perform the lookup has to match that. I’m thinking the best thing might be to manipulate the rounded date/time sensors at the point where I interrogate the array.

10

Did you remove the %z from the format?

And you need to remove the device_class line from the sensor config.

name: Sunrise Tomorrow
unique_id: sunrise_tomorrow
state: |
  {% set adj_time = state_attr('sensor.home_sun_rising','tomorrow')
  + timedelta(hours=now().timetuple().tm_isdst) %}
  {{ adj_time.strftime('%Y-%m-%dT%H:%M:%S') ~ '+0100'}}
1 Like
11

@jan-tdy, I need to round tomorrow’s sunrise and sunset times to the nearest five minutes, and I think I need a template sensor to do that.

1 Like
12

Thank you @Didgeridrew and @jan-tdy, the underlying issue was the device_class timestamp. As per the Gemini link: “When you define a sensor with device_class: timestamp, Home Assistant ignores your custom string formatting and internally converts the value to a Python datetime object in UTC”. When I removed the device_class from the rounded sunrise and sunset sensors, these remained as strings and worked fine for querying the array.

1 Like
13

see?
before posting here, try ai.

14

May I suggest using the sun2 integration instead.
Its better implemented, because it is not bound to the altitude in HA, and it has mutiple sensors for sunrise and sunset, so you will never get the issue with sunset before sunrise or vice versa.

1 Like
15

Hi @WallyR, I do use the sun2 integration as well for other things. In this case, whether I use the built-in sun integration or the sun2 integration, I’d still need to use the attribute ‘tomorrow’, and I’d still need to round it to the nearest five minutes, so it wouldn’t make any difference.