The EPIC Time Conversion and Manipulation Thread!

[petro]

@Mariusthvdb

This has worked up to the time change in recent HA update.

what has worked up to this timechange? strptime on timedeltas, that’s not true. You’re mixing up functionality. Strfttime, and strptime has never worked on timedeltas, only datetimes.

just think of it this way:

What’s tuesday - monday? 1 day. Ok, what day of the week is that? Don’t have an answer? That’s because there is no answer, hence why strftime and striptime do not work on timedeltas. Because timedeltas are a change in time. Stftime and strptime include formats that would not be possible on a time delta, like %A which is the day of the week as a word.

[Mariusthvdb (Marius)]

sorry, should have been more specific… I meant to say, the first template here worked fine up to the time change in HA. It showed the time in HH:MM m and now shows the microseconds output.

so I need to manipulate that back in to HH:MM

[petro]

Na, you’re still miss remembering. Timedetla’s string repr has not changed in 20 years. It has always been d:hh:mm.ssssss.

[petro]

it’s possible that the datetimes didn’t track microseconds which didn’t translate to the timedelta, but you would have still gotten a day and zero all the way out.

[petro]

anyways…

@Mariusthvdb

      daylight_remaining_hm:
        friendly_name: 'Daylight remaining hh:mm'
        value_template: >
          {%- set nw = now() %}
          {%- set sr = state_attr('sensor.astral_sunrise', 'today') %}
          {%- set ss = state_attr('sensor.astral_sunset', 'today') %}
          {%- macro hhmm(dt) %}
            {{- '{0:02d}'.format(dt.seconds // 3600 % (3600)) }}:{{ '{0:02d}'.format(dt.seconds // 60 % 60) }}
          {%- endmacro %}
          {%- if nw < sr %}
            {{ hhmm(ss - sr) }}
          {%- elif nw < ss %}
            {{ hhmm(ss - nw) }}
          {%- else %}
            00:00
          {%- endif %}

or if you want the days, remove the microsecond

      daylight_remaining_hm:
        friendly_name: 'Daylight remaining hh:mm'
        value_template: >
          {% set nw = now().replace(microsecond=0) %}
          {% set sr = state_attr('sensor.astral_sunrise', 'today').replace(microsecond=0) %}
          {% set ss = state_attr('sensor.astral_sunset', 'today').replace(microsecond=0) %}
          {% if nw < sr %}
            {{ ss - sr }}
          {% elif nw < ss %}
            {{ ss - nw }}
          {% else %}
            0:00:00
          {% endif %}

[Mariusthvdb (Marius)]

thanks!

btw it was this change I referred to, that causes the issue: Release Handle new time zone type in HA core · pnbruckner/ha-sun2 · GitHub

Home Assistant changed the details of its time zone implementation, starting w/ 2021.6.x. Specifically, it switched from the pytz package to Python’s new native zoneinfo library.

as you can see here, I did try the microsecond removal myself, but thought it hacky… though at the time I thought it showed only HH:MM and not :SS too… maybe not.

[Mariusthvdb (Marius)]

got another one, new to me so please have a look if I do this correctly:

mqtt topic returns 2021-08-02T20:34:03Z which is Zulu time, as I’ve been explained by Tinkerer, and is also touched atop in this thread.

Now of course I want local time so I can use device_class timestamp, and created this value_template

  - platform: mqtt
    state_topic: watermeter/smart_gateways/startup_time
    name: Watermeter Startup time
    value_template: >
      {{value.split('Z')[0]}}
    device_class: timestamp

and yes, that returns alright. I was wondering though if I shouldn’t be doing an official time manipulation instead if this string manipulation.

thanks for having a look

[koying (Chris B)]

{{ as_datetime(value)|as_local }}

should work, nowadays, doesn’t it?

[Mariusthvdb (Marius)]

@koying

{{ as_datetime(value)|as_local }}

thanks!, but no it doesnt. this is what I had:

and this is what your suggestion renders without it being set as timestamp:

with timestamp:

[koying (Chris B)]

Indeed. I’m always confused about what device_class: timestamp actually expects.
I redid the test, and the UTC time correctly display in my local TZ w/o transformation.

Are you saying that the UTC time returned by MQTT is not actually UTC but local?
Then, it’s just wrong, and you have to “correct” it manually, indeed, no magic here.

OTOH, there might be a setting on whatever sends the message to set the correct TZ…

[Mariusthvdb (Marius)]

no the Z time is Utc alright, and local is +2
if I simply take the value and use timestamp I get this:

confuses me even more, because that seems to be correct…
ill reboot the device and see what happens…

right:

so Ive got to go back to the original then

[123 (Taras)]

Another way to do it:

    value_template: >
      {{ as_datetime(value).isoformat() }}

[Mariusthvdb (Marius)]

thanks Taras, that too is 2 hours off…

this is really odd:

though the top 3 seem identical in the states, only the split(‘Z’) has the correct local time

  - platform: mqtt
    state_topic: watermeter/smart_gateways/startup_time
    name: Watermeter Startup time
    value_template: >
      {{value.split('Z')[0]}}
#      {{as_datetime(value).isoformat()}}
#      {{value}}
#      {{as_datetime(value)|as_local}}
    device_class: timestamp

[123 (Taras)]

@Mariusthvdb

that too is 2 hours off…

Where is it 2 hours off? The example I posted, using the datetime string you provided (Zulu time = UTC), clearly shows the resulting ISO8601 string remains as UTC.

It converted this:

2021-08-02T20:34:03Z

to this:

2021-08-02T20:34:03+00:00

[koying (Chris B)]

Doesn’t really make sense.

The plain value works for me:

    test_timestamp:
      value_template: "2021-08-03T20:34:03Z"
      device_class: timestamp

Just to be sure, “2021-08-03T22:34:03+02:00” doesn’t mean you have to add 2h to “22:34”. “+02:00” is the TZ, so that datetime is 22:34 in my TZ, UTC+2

[petro]

The problem for you is when you remove the z and use as_datetime, it removes UTC and treats it as local. That means, it’s not really a zulu timestamp.

[Mariusthvdb (Marius)]

what would be the exact remark I should bring across to the author here…

what is still confusing me is, that the Z is correct for the Utc time is 2 hours behind my zone, and when using that it shows the correct time difference.

My issue is to show that Z time in my local time

@123

It converted this:

yes, in the template editor, but did you also use it in the frontend and using device_class: timestamp?

[Mariusthvdb (Marius)]

separate topic, trying to use the {{as_datetime(0|timestamp_utc).isoformat()}} jinja template in JS.
Python uses dt.utc_from_timestamp(0)
please help me translate this?
Having a hard time here, because the online tutorials dont use the jinja used here…
thanks

[123 (Taras)]

@Mariusthvdb

did you also use it in the frontend and using device_class: timestamp?

This Template Sensor:

      water_meter_test:
        friendly_name: Watermeter Startup time
        value_template: "{{ as_datetime('2021-08-02T20:34:03Z').isoformat() }}"
        device_class: timestamp

looks like this in Developer Tools > States:

and like this in the frontend:

Popup:

[BenHornerTech]

I’m sure this is a simple thing, but I can’t figure this one out.

I want to compare the time from a sensor attribute to the current local time in minutes. The outputs for now() and the attribute are:

Now: {{ now() }}
Attribute: {{ state_attr("sensor.my_sensor_name","LastUpdated") }}

displays:

Now: 2021-08-05 10:30:00.001533+01:00
Attribute: 2021-08-05T10:29:41Z

Both seem to show about the same time with the attribute being 19 seconds behind now, which is what I expect. If I convert both of those with as_timestamp, I get:

Now as timestamp: {{ as_timestamp(now()) }}
Attribute as timestamp: {{ as_timestamp(state_attr("sensor.my_sensor_name","LastUpdated")) }}

displays:

Now as timestamp: 1628155860.00095
Attribute as timestamp: 1628159441.0

This for some reasons is showing a difference of 3581 seconds. I’m assuming this is because of daylight savings and my current local time is +1, but I don’t want to just use a hacky -3600 bit of maths as this will break each time we switch from daylight savings. Where am I going wrong?