it doesn’t matter, choose your poison. They all give the same answer when used in an if statement.
but what exactly does the 0/1 stand for? is it no/true or 0/1 hours
do you know where the timetuple() is documented btw?
does the day_to_event count down to 0? I’d like to do something like:
- alias: Dst change clocks
trigger:
- platform: time
at: '10:00'
- platform: time
at: '19:00'
condition:
condition: template
value_template: >
{%- set next = state_attr('sensor.dst','next').days_to_event %}
{({trigger.now.strftime('%H:%M') == '10:00' and next == 0) or
(trigger.now.strftime('%H:%M') == '19:00' and next == 1)}}
action:
- choose:
- conditions: >
{%- set next = state_attr('sensor.dst','next').days_to_event %}
{{next == 0}}
sequence:
service: input_boolean.turn_on
entity_id: input_boolean.dst
- service: notify.system
data:
message: >
{%- set next = state_attr('sensor.dst','next').days_to_event %}
Daylight savings starts {{'today' if next == 0 else 'tomorrow, please update all
clocks manually if necessary.'}}
to reveal a button on the input_boolean being ‘on’ on the actual day. This would work if after 1 it immediately counts to the next dst change…
A quick Internet search reveals the answer.
From here: datetime.timetuple() in Python | Pythontic.com
If the
tzinfohas the daylight saving settm_isdstwill be set accordingly as0or1. Else,-1will be set fortm_isdst.
thanks, and of course, it was python 
but now, this is still confusing? it will be set to -1if the tzinfo doesnt have the daylight saving set. I guess I can forget about that, because my tzinfo has it set. In which case it will either be 0 or 1, as in off /on ? Or does it mean plus 0 hours/plus 1 hour.
Iow, is it boolean or numeric?
couldn’t resist adding:
{%- set clock = 'ahead' if next == ns.spring else 'back' %}
{"spring": "{{ns.spring.isoformat()}}",
"fall": "{{ns.fall.isoformat()}}",
"event": "{{next.isoformat()}}",
"days_to_event":{{(next-today).days}},
"phrase": "{{phrase}}",
"clock":"{{clock}}" }
to facilitate the icon customize…since I don’t hide them
sensor.dst:
templates:
icon: >
return attributes.next.clock == 'ahead' ? 'mdi:update' : 'mdi:history';
icon_color: >
return attributes.next.clock == 'ahead' ? 'maroon' : 'green';
I’m struggling to see why it’s so important…?
if it will ever be only a 0, 1, or potentially rarely a -1 what difference does it make if it’s representing hours or a boolean? or I guess it’s a “three value” boolean - on/off/undefined.
1 Like
well, yeah, it is. can’t believe you don’t feel like that too?
there s a whole different meaning to ‘1’ saying ‘yes, time is in dst mode’ than ‘1’ saying ‘we are 1 hour ahead of time’
in a system where the difference between an unquoted boolean and a quoted one (making that a string) is so important, that does strike me as fundamental tbh. I just want to know, and hence understand.
I suppose you are correct: on/off/defined. in which case the template should be
{{ now().timetuple().tm_isdst == 1 }}
after all.
next thing for me to understand is if the day_to_event counts down to 0. I need to set a boolean, or binary_sensor for that.
I guess I could also do that based on a state change from {{now().timetuple().tm_isdst}}, but Id have to make sure it would trigger in the obscure -1…
not really. those two statements are fundamentally identical.
‘yes, time is in dst mode’ == ‘we are 1 hour ahead of time’
When would that not be true?
If you include the sections above I added to petro’s template (which were just CO_4X4’s templates added as additional attributes) then you will already have a boolean to use - just use the attribute value.
If your timezone already has a setting for DST active or not (1 or 0) then I doubt you would ever have to deal with a -1 in the future. I doubt that TZ info gets changed to eliminate the dst setting very often.
and besides, using the " > 0 " instead of " == 1 " solves those situations if it would ever come up. If you are undefined or 0 then you are not in dst. If it is a 1 for your TZ then you are in dst.
1 Like
I’m not sure this discussion is going anywhere BUT : -
I’m surprised at this, especially given that @finity is part of the discussion as I had always considered this to be relative to UTC. Obviously the distinction is moot to Marius as he is in CET so UTC +1 is quite normal for him. The fact that you are both talking DST = TZ + 1 proves it to be local (obvious given the miriad of differing ways DST starts and stops) so the rules are specific to the selected TZ and all run on the standard TZ offset unless DST is applied.
Thinking about it this, there is no other way this could work, and from observance of the discussion the - 1 indicator should only come into effect if the system ‘doesn’t know’. Hard for that to happen if it knows the UTC (from the internet/RTC) AND the TZ. So I’m left guessing, maybe: - booting a pi without an Internet connection ?
So I’d just take the isdst value.
I do kinda think that the whole thing is kinda moot
Why does it matter ?
Re home automation you either want something to happen on a clock based on the time the humans operate in (local time) or you want it to happen on a fixed period, in which case you’d have those automations run on UTC anyway.
The only other considerations are : -
- “I need a reminder to put my (dumb) clocks forward or back”
- (DST changes for me always occur in the small hours of a Sunday morning) So this may need a higher priority for shift workers (finity as a case in point)
- “I always phone my mother/child/other family member (in another TZ) on a sunday morning and don’t want to get them out of bed” [personal note: Anytime on a Sunday morning is likely to get me out of bed
]
I’d be most interested in the effects of this for finity as a representative of ‘shift workers’ but : -
- Most ‘shift workers’ manage quite well (from observation)
- The percentage of ‘shift workers’ who a) have HA b) have the ability to follow this discussion c) care enough to implement the ‘collected wisdom’ must be a tiny proportion.
What have I missed.? Its obviously a biggie but I can’t see what it is.
2 Likes
hence the original confusion on my part… as time changes I’ll be on Utc+2 and so I had to be sure the tm_isdst being 1 didn’t indicate a +x hour, but indeed a yes/no.
all of these for me, well. mostly 1 and 2, but you’re missing out on what maybe the most important one:
being able to have an hour of extra sleep, or just the opposite of that, is essential to ones mental well being the next morning, heck, even the night before. That glorious feeling we’re allowed to have once a year, we don’t want to let that pass unnoticed… 
That’s offset by the extra grouchyness on the flipside of the year (usally for us Northern Hemisherers to be 5 months later) 
still struggling… I need a binary for a today’s dst setting change: today dst changed.
both binaries are added to the template, but neither off them says so. the first says only if dst is active today, the second indicates tomorrow dst will change…
If only I would know if petros day counter would go down to 0, I could use that.
What am I missing here (going round and round in circles)
or, would this do that:
dst changed today: >
{% set dt = now() + timedelta(days=-1) %}
{{ now().astimezone().tzinfo != dt.astimezone().tzinfo }}
Ever wonder “why did I add this contribution” after seeing it go from a simple contribution of a few lines of YAML code to a debated project encompassing dozens of lines of code and arguments over how that code should be interpreted?
Or is it just me? 
2 Likes
nope, true.
that’s what you get when you share useful code
here’s a bit more:
- alias: Dst change clocks
trigger:
- platform: time
at: '10:00'
- platform: time
at: '19:00'
condition:
condition: template
value_template: >
{{(trigger.now.strftime('%H:%M') == '10:00' and
state_attr('sensor.dst','dst changed today') == true) or
(trigger.now.strftime('%H:%M') == '19:00' and
state_attr('sensor.dst','dst change tomorrow') == true)}}
action:
- service: notify.system
data:
title: >
Dst {{'tomorrow' if state_attr('sensor.dst','dst change tomorrow') == true
else 'today'}}
message: >
{% set today = state_attr('sensor.dst','dst changed today') %}
{% set change = state_attr('sensor.dst','next').clock %}
{% set suffix = 's' if today == true else 'ed' %}
Daylight savings start{{suffix}} {{'today, please set all
clocks 1 hour ' + change + ' manually if necessary.' if today == false else 'tomorrow'}}
- condition: template
value_template: >
{{state_attr('sensor.dst','dst changed today') == true}}
- service: input_boolean.turn_on
entity_id: input_boolean.dst
If it helps any I was quite happy with your original code. 
The only thing I changed was I turned it into a binary sensor instead of a regular sensor so it was easier to trigger a reminder automation.
But petro’s code gave more info so I incorporated your code into his for the best of both worlds.
I’m not having any issues at all interpreting the code.
I don’t get what you are having an issue with.
that attribute will be true if “dst active” will change tomorrow otherwise it’s false (by definition a binary sensor).
So if that attribute is true you can use that to trigger a notification the day prior so you remember to set the clocks accordingly.
The “thinking” is done for you in the automation.
Here are a couple of automations to send a pushbullet notification in the morning and make an announcement at night to remind you. They are solely based on the original code in the first post except I made them binary sensors instead or non-binary:
- alias: 'Notification DST'
trigger:
- platform: state
entity_id: binary_sensor.dst_change_tomorrow
to: 'on'
action:
choose:
- conditions:
- "{{ states('binary_sensor.is_dst') == 'off' }}"
sequence:
- service: notify.pushbullet_notify
data:
message: 'DST time starts tomorrow. Set the clocks ahead tonight.'
- conditions:
- "{{ states('binary_sensor.is_dst') == 'on' }}"
sequence:
- service: notify.pushbullet_notify
data:
message: 'DST ends time tomorrow. Set clocks back tonight.'
- alias: 'TTS DST'
trigger:
- platform: time
at: '23:00:00'
action:
choose:
- conditions:
- "{{ states('binary_sensor.dst_change_tomorrow') == 'on' }}"
- "{{ states('binary_sensor.is_dst') == 'off' }}"
sequence:
- service: notify.alexa_media
data:
target:
- media_player.computer_room_dot
- media_player.kitchen_dot
- media_player.garage_dot
- media_player.basement_dot
- media_player.livingroom_dot
- media_player.sunroom_dot
data:
type: tts
message: "Daylight Savings Time starts tomorrow. Don't forget to set the clocks ahead."
- conditions:
- "{{ states('binary_sensor.dst_change_tomorrow') == 'on' }}"
- "{{ states('binary_sensor.is_dst') == 'on' }}"
sequence:
- service: notify.alexa_media
data:
target:
- media_player.computer_room_dot
- media_player.kitchen_dot
- media_player.garage_dot
- media_player.basement_dot
- media_player.livingroom_dot
- media_player.sunroom_dot
data:
type: tts
message: "Daylight Savings Time ends tomorrow. Don't forget to set the clocks back."
Indeed I seem to have failed to make that happen 
As I have been trying to bring across, I want a binary for the ‘today’ change. Because I don’t only want a headsup for tomorrows change, I also want a reminder on the day itself, to reset the clocks.
so I added the extra attribute (binary) to make that possible.
My automation does it all as far as I can see now, both for tomorrow and today. Ive edited the message to incorporate the sleep indication for case tomorrow
- alias: Dst change clocks
trigger:
- platform: time
at: '10:00'
- platform: time
at: '19:00'
condition:
condition: template
value_template: >
{{(trigger.now.strftime('%H:%M') == '10:00' and
state_attr('sensor.dst','dst changed today') == true) or
(trigger.now.strftime('%H:%M') == '19:00' and
state_attr('sensor.dst','dst change tomorrow') == true)}}
action:
- service: notify.system
data:
title: >
Dst {{'tomorrow' if state_attr('sensor.dst','dst change tomorrow') == true
else 'today'}}
message: >
{% set today = state_attr('sensor.dst','dst changed today') %}
{% set change = state_attr('sensor.dst','next').clock %}
{% set phrase = state_attr('sensor.dst','next').phrase %}
{% set suffix = 's' if today == false else 'ed' %}
Daylight savings start{{suffix}} {{'today, please set all
clocks 1 hour ' + change + ' manually if necessary.' if today == true else
'tomorrow, you will ' + phrase + ' of sleep'}}
- condition: template
value_template: >
{{state_attr('sensor.dst','dst changed today') == true}}
- service: input_boolean.turn_on
entity_id: input_boolean.dst
@petro Did you find a way to deliver the DST info for a different timezone to your local one?
Just a minor FYI - your code assumes Spring comes before Fall in your code. Not true in the southern hemisphere !
getting back to this, because the frontend representation of the timestamp device_class is somewhat peculiar:
stating ‘In 1 day’:
while in fact is is 2…
today is the 26th… so the more-info is correct on all attributes and state.
Sorry to dig up this thread.
Does anybody have a simple boolean sensor that returns TRUE during winter time and FALSE during summer time? Or vice-versa?
I use the following binary template sensor for that:
binary_sensor:
- platform: template
sensors:
sommerzeit:
friendly_name: "Sommerzeit"
icon_template: "mdi:weather-sunny"
value_template: "{{ now().timetuple().tm_isdst == 1 }}"