Users of `strptime()` and possibly other date/time functions beware - January 2022 changes

Configuration
1

I use the “SSL countdown timer” suggested by Danny at Smart Home Pursuits. This fetches a timestamp for when the SSL certificate runs out and puts it into a sensor. A template sensor is then used to calculate a countdown in days till the SSL certificate runs out. I have found this to be a great help and it displays nicely in a gauge.

However, from Jan 2022 though, the strptime and as_timestamp methods both require a default value to be added! Zero (0) is a suitable value though changing the logic a bit to detect use of the default is a further step to avoid getting silly large values displayed when the defaults get used. I have not done this…

A more serious issue is that the behaviour of the date/time manipulation function strptime() has changed as well.

In the past a partial format pattern could be used to match from the start of the provided time string, hence YYYY-MM-DD or similar was OK. Now, a few tests using the Developer Tools for templates in Jan 2022 show that the strptime() format pattern string has to match every character in the provided time string.

So you could change the format from %Y-%m-%d to something like %Y-%m-%dT%H:%M:%S+00:00 which works for me in UTC time. You cannot use %z to match the time zone +00:00 as it does’nt match the : given in e.g. my current timeout of: 2022-04-24T09:47:54+00:00. Yet again, you could do some string manipulation on the provided time before use. This is indeed the solution giving :

strptime(states(("sensor.shp_cert_issued.state")[:-15]),  "%Y-%m-%d",  0)

Note: The change to function “states”, extra speech marks round argument + brackets to force evaluation of the function result compared to the Smart Home Pursuits website referenced above. Its last 15 characters chopped off the time value (…[:-15]) before being fed into strptime() that fixes the problem described here so it works now correctly again in my HA. You may need to adapt your code in other ways!

The question is: Was the change to always needing to exactly match the string & patterm/format arguments rather than just the start of the provided time string deliberate? I think it might break quite a few people’s code even once they have added the now required default values.

2

This has never worked. matching "%z" is dependent on the python version. "%z" matches "+0000" (Notice the absence of the colon?), and "%Z" matches the name (like "UTC", or "EST", or "GMT").

There was no such change. The only change that has occurred is that strftime requires a default. All the rest of this post is just your findings on how strftime has always worked.

3

Secondly, if you have a fully fleshed out timestamp… i.e.

You can convert it into a integer float representing time in seconds from jan 1st 1970…

{{ as_timestamp('2022-04-24T09:47:54+00:00') }}
{{ '2022-04-24T09:47:54+00:00' | as_timestamp }}

or a utc datetime

{{ as_datetime('2022-04-24T09:47:54+00:00') }}
{{ '2022-04-24T09:47:54+00:00' | as_datetime }}

or a datetime with your TZ

{{ as_local(as_datetime('2022-04-24T09:47:54+00:00')) }}
{{ '2022-04-24T09:47:54+00:00' | as_datetime | as_local }}
1 Like
4

And just to add some proof that nothing changed in that regard, here’s a template from 2019 that dances around the problem of the colon in a strptime/strftime

            {%- set t = strptime(t_string+"-+0000", "%Y-%m-%d,%H:%M:%S-%z") %}