Hi
After upgrading to 0.118 seems that the datetime in python script is returning UTC and not local time. Is this the case?
Any solution?
Thx
More information:
In previous HA versions, calling the following returns correct local time:
"{{ as_timestamp(states('input_datetime.reminder2_date')) | timestamp_local }}"
in 0.118 I need to change it to UTC to get correct local time.
"{{ as_timestamp(states('input_datetime.reminder2_date')) | timestamp_utc }}"
Any idea why?
The good news is that it’s a known problem, there’s an open Issue in the Core repository, balloob is taking care of it and has created a PR to correct it. You can follow the discussion here:
1 Like
Ended up here trying to find a way to get the current time in seconds in the local timezone in order to update my lights correctly in a circadian rhythm script I’ve written. Previously I used datetime.datetime.now(), but that returned a datetime in UTC. Tried using the dt_util.as_local, but that seemed to return the same datetime. Tried to use the dt_util.get_time_zone in order to create a tzinfo object to pass to datetime.datetime.now(), but that also failed because access to dt_util.get_time_zone is restricted.
Finally realised that there is a dt_util.now() function and looking at the source code, it seemed to use the default timezone! This actually works and I now am able to get the correct amount of seconds using datetime.timedelta(hours=now.hour,minutes=now.minute,seconds=now.second).total_seconds()
Shame there seems to be no documentation for the dt_util library and the documentation for the Python scripts is also rather minimal. Hope that others struggling with this issue find this and are able to solve their issues.
1 Like
I know this is a very
I know that this is a very old thread, but yes, your answer helped me. Unfortunately the Python scripts documentation is still almost non-existent. Which is a bummer for me, because before I write more than a single line of jinja in a YAML-file I’d rather create a Python script, even though there’s a lot more boiler plate code necessary. It’s just so much easier to read, write and debug.
Before I found your post my way to get a timezone value was to pick it off a date created with fromisoformat(), which returns a datetime with a tzinfo property, and then fed it to datetime.datetime.now() like
datetime.datetime.now(datetime.datetime.fromisoformat('2026-07-18 00:00:00.000+00:00').tzinfo)
I couldn’t believe that round-about way had to be the solution (and I don’t understand why the timezone class of the datetime module isn’t accessible) just to be able to subtract “now” from given date (which ran into a “can't subtract offset-naive and offset-aware datetimes” Python error). dt_util.now() is obviously much more readable. So thank you!