The EPIC Time Conversion and Manipulation Thread!

[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?

[koying (Chris B)]

From a pure datetime perspective, it is correct.
Likely, whatever produced the “LastUpdated” attribute is wrongly configured, and thinks the date/time it has is utc rather than utc+1.

[BenHornerTech]

Oh dear - so no way to fix it at my end?

[koying (Chris B)]

Well, what provides “LastUpdated”. Isn’t there a TZ config at that end?

[BenHornerTech]

Most likely, but it’s actually an external REST API that I am calling, so I don’t have control over it.

[petro]

It’s actually a debate that Z means zulu time. There are references on wikipedia that state Z means zulu time, which apparently is GMT or UTC1, and there are references that state it means zero i.e. UTC. Either way, it seems that the user needs to figure this out for their application.

[123 (Taras)]

What does this report on your system?

{{ (utcnow() - as_datetime(state_attr("sensor.my_sensor_name","LastUpdated"))).seconds }}

Same result or different?

[koying (Chris B)]

@petro

It’s actually a debate that Z means zulu time

Is there? GMT = UTC, but I’d be surprised if a source defines it as UTC+1