Ah lots of replies, great! Thanks!
I’m not very familiar with the solutions (need to study them a bit more) but the most seem to do the trick! Nice work.
How could this be modified to find out if tomorrow is the last Wednesday of the month? I need a notification to take out the glass recycling bin the night before. I originally thought that finding the last Tuesday of the month would be appropriate, but then I realized that the last Tuesday could preceed the first Wednesday, which wouldn’t work.
I thought this might work, but it errors if tomorrow is next month.
{{ now().date().replace(day=now().day+1) }}
Here’s what I settled on:
{% set next_month = now().date().replace(day=28) + timedelta(days=4) %}
{% set last_day = next_month - timedelta(days=next_month.day) %}
{% set last_wednesday = last_day - timedelta(days=last_day.weekday() - 2 ) %}
{{ now().date() == ( last_day.replace(day=last_day.day-1) if last_day.weekday() == 2 else last_wednesday.replace(day=last_wednesday.day-1)) }}
{% set t = now() + timedelta(days=1) %}
{{ t.isoweekday() == 3 and t.month != (t + timedelta(days=7)).month }}
First line: Variable t is tomorrow.
Second line: Check if tomorrow is Wednesday and in 7 days it’s a different month.
2 Likes
wow, this really is practically the only topic I could find calculating a ‘last’ day. Sorry to revive, but since its really connected to your post here, Id rather not take it elsewhere.
using a generic DST template currently, which iterates over all days in a given range (spanning more than a year to catch some variance), would it be possible to adapt this to find the next 2 ‘last Sunday’ occurrences in month March and October.
Since these are the fixed dates for DST change, that might be more efficient? only 2 months to check, finding each last Sunday?
just having changed DST, I would like the template to output October and March next.
Otoh, If it wouldn’t be much faster, there s is no use?
Why did you switch from the DST template I gave you 2 years ago? It’s still working for me and calculates the transition down to the minute. It’s also light weight for it’s operations.
hi!
it refused to output here in range(365) the other day, so I had to check, and then things changed a bit, see the linked topic above,
also, it didnt change the output immediately after the change, and waited the day, which I would like to change.
Because you never updated it to the current one I just linked…
? never saw that really. Was that posted in that topic?
Yes
But the one in my repo may be more up to date.
no, apparently not. sorry bout that.
how does this then find the next 2 events, like the other template does?
must have a closer look ofc…
heck I now see this: Daylight Savings Time (DST) - Template and Automation - #59 by Mariusthvdb
still sitting tight I guess 
It searches ahead for the change in the day, then it searches ahead for the hour in the day, then the minute. At most it’ll be 365 + 24 + 60 iterations. In reality, most DSTs change within 182 days, 2 hours and 0 minutes. Making it around 184 iterations.
No, that change was made a long time ago, simply remove the .isoformat(). That’s updated what I linked
it still outputs: 2023-10-29 03:00:00+01:00
without the T there, so (a mMac) wont display that correctly when used as timestamp?
the beauty of the earlier template is that it calculates 2 dates, for spring and fall change. Id love to keep those really
No? Timestamp sensors in home assistant require a datetime object being the output. They all output without the T. The T is part of ISOs format.
ok let me test that, I had difficulties with those before, especially on Mac, but maybe that hs changed.
I’m not sure how you could have had ‘difficulty’ with them when HA does all the work. Also, keep in mind that all timestamp sensors are like this, i.e. ones that come from integrations that you have no control over.
EDIT: And once you create the sensor, you’ll see the T is in the state too. HA does this beyond the template.
it said ‘Invalid format’ in the frontend.
there are still some idiosyncrasies there, check this
entity in an entities card, without anything further:
clicking that reveals:
note the actual date in the state, and the datetime s in the attributes
3 different formats for a single template syntax…
The old template is wrong and does not work. You can’t trust it. The new template works. As for the entities card, that’s what HA does with timestamps, that has nothing to do with the template itself.
the template is correct…
Keep in mind that 2am is 3am when DST is not applied. So the timestamp is correct it just doesn’t say ‘3am’, however the number of days, hours, and minutes from now to dst is correct.
btw, this is what I referred to: Templating - Home Assistant
the yellow warning above that:
If your template is returning a timestamp that should be displayed in the frontend (e.g., as a sensor entity with
device_class: timestamp), you have to ensure that it is the ISO 8601 format (meaning it has the “T” separator between the date and time portion). Otherwise, frontend rendering on macOS and iOS devices will show an error. The following value template would result in such an error:
{{ states.sun.sun.last_changed }}=>2021-01-24 07:06:59+00:00(missing “T” separator)To fix it, enforce the ISO conversion via
isoformat():
{{ states.sun.sun.last_changed.isoformat() }}=>2021-01-24T07:06:59+00:00(contains “T” separator)