How to show date of last Wednesday of the month?

Configuration
25

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?

26

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.

27

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.

28

Because you never updated it to the current one I just linked…

29

? never saw that really. Was that posted in that topic?

30

Yes

But the one in my repo may be more up to date.

31

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 :wink:

32

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.

33

No, that change was made a long time ago, simply remove the .isoformat(). That’s updated what I linked :wink:

34

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

35

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.

36

ok let me test that, I had difficulties with those before, especially on Mac, but maybe that hs changed.

37

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.

38

it said ‘Invalid format’ in the frontend.

there are still some idiosyncrasies there, check this

entity in an entities card, without anything further:

Scherm­afbeelding 2023-03-27 om 13.22.04
Scherm­afbeelding 2023-03-27 om 13.22.04984×138 8.16 KB

clicking that reveals:

Scherm­afbeelding 2023-03-27 om 13.21.54
Scherm­afbeelding 2023-03-27 om 13.21.541130×856 65 KB

note the actual date in the state, and the datetime s in the attributes
3 different formats for a single template syntax…

39

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…
image

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.

40

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)

41

Yes, but you’re not understanding what HA does under the hood.

device_class:timestamps REQUIRE a datetime object being returned. Not a string. This is a requirement. So using isoformat() will result in an error in the logs. After the template is resolved, HA will take the datetime object and format it in isoformat. Just look at the state of the sensor in developer tools instead of arguing. You’ll see that the state has a T in it. The template in the template editor will not have the T because it hasn’t been resolved by the template sensor code.

image
image1052×65 9.09 KB

42

yes, that is correct, (for the state, not the attributes though)

Scherm­afbeelding 2023-03-27 om 13.36.26
Scherm­afbeelding 2023-03-27 om 13.36.261862×622 67.3 KB

not arguing here, simply trying to understand why things are not equal throughout the system.

given the state used here is

{{([ns.spring,ns.fall]|min)}}

and the attributes are:

            {%- set next = [ns.spring, ns.fall] | reject('<',now())|min %}
              {"spring": "{{ns.spring}}",
             "fall": "{{ns.fall}}",
             etc etc

wouldn’t it be expected these attributes also show the T?

well, it was a bit quirky with the range set too tight, now it does work correctly

43

No because you aren’t using isoformat. You’re just outputting the datetime as a string. Remember device_class: timestamp has extra steps to turn datetimes into iso formatted datetime strings. Attributes do not, so you have to do it.

1 Like
44

It does not work, it will be off by an hour. There is no way to get the correct time of the second transition due to the nature of DST. It will always be off by 1 hour.

EDIT: Well there probably is a way but it would be a ton of work for no gain. You’d have figure out your next loss/gain and inverse that value on the following loss/gain.

1 Like