The EPIC Time Conversion and Manipulation Thread!

[Mariusthvdb (Marius)]

have been around for this before, but am having trouble again.

an mqtt sensor has value

2022-03-06T16:02:11Z and my local time is 1 earlier than that.

I want it to show a timestamp (and have the frontend show the relative time) so use:

{{as_datetime(value).isoformat()}} # or
{{as_datetime(value)}}

resulting in

which is still an put off.

trying as_local Adds an hour…

now how do I get it to subtract that 1 hour…?

I did see the Zulu time being mentioned as early in this thread as The EPIC Time Conversion and Manipulation Thread! - #11 by finity but it doesnt really help me find the answer.

[petro]

All 3 are identical time. One is your local time, the other are utc. If the time is wrong, that means your input is wrong.

[Mariusthvdb (Marius)]

you mean the source?

just tried:

{{value|as_timestamp|timestamp_local}}

resulting in

its not really very important, and no system automation depend on it, I just like to get it right…

[finity]

It seems that your system thinks you are in a TZ 1 hour ahead of UTC instead of an hour before.

[petro]

Yes, so if you were to take the +1 hour of your time zone and subtract it from local you get utc. If the input time is local, then you need to convert it as a local timestamp, not utc like you’re doing

[Mariusthvdb (Marius)]

yes, exactly… but my system time is ok

[petro]

This is both of you not understand that the conversion is treating the sting as utc. Make it timezone agnostic by removing the Z. Then use as datetime and as local

[finity]

nevermind I misread the problem and got my +1 & -1 reversed.

I think based on this:

@Mariusthvdb

my local time is 1 earlier than that.

[Mariusthvdb (Marius)]

right!

went from

to

and is still an hour off, because now it states the 16:02 time (and it should show 15:02)

full disclosure:

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

[petro]

Yes there’s 3 types of datetimes: local, utc, and none. None has no concept of a what timezone it is, so you can then attach one to it… by using as_local.

[Mariusthvdb (Marius)]

Guess I have to manipulate the time manually with an offset , this says it all

Restarted and see:

[petro]

Listen, if the time is local and not utc you have to treat it as local. I don’t know how else to explain this to you. If they are attaching Z and your time is wrong, then they are giving you the wrong timestamp. Removing z doing as_datetime | as_local will give you that time as your local time. Do not use as_timestamp. Do not use anything else.

[petro]

If the time is supposed to be @15 and it’s reporting 16, then they are giving you wrong information. Plan and simple. Your timezone is plus 1. Minus 1 is in the ocean and a minus 1 is the only way local or utc would give you 15.

[Mariusthvdb (Marius)]

@petro

Removing z doing as_datetime | as_local will give you that time as your local time. Do not use as_timestamp. Do not use anything else.

thanks Petro, still the same though (but missing out on the T I need in the Mac ecosystem)

I’ll notify the author of the Watermeter software and ask him to change accordingly.

[petro]

If the last one is off by an hour, then the time is wrong.

[petro]

Now that I’m at a computer, dt.tzinfo shows you your time zone info. So after you convert a time string using as_datetime, you can see the results.

Pasting this code will show you the differences:

x


{%- macro doit(dt) %}{{ (dt | string).ljust(25) }} | {{ dt.tzinfo }}{%- endmacro %}
{% set value = '2022-03-06T16:02:11Z' %}
{{ doit(value | as_datetime) }}
{{ doit(value.replace('Z','') | as_datetime) }}
{{ doit(value.replace('Z','') | as_datetime | as_local) }}

2022-03-06 16:02:11+00:00 | UTC
2022-03-06 16:02:11       | None
2022-03-06 16:02:11+01:00 | whatever TZ this is

Your time zone is +1 currently (possibly with DST?)

Assuming that you are correct with your claim that it’s off by an hour and it should be 15, then the datetime should be one of the following:

If the time string is meant to be UTC then it should be should be showing 2022-03-06T14:02:11Z.
If the time string is meant to be local, then it should be showing 2022-03-06T15:02:11 with the assumption that you add the time zone.

So, no matter what, the input time string is wrong.

This of course is making a few assumptions:

1. It’s supposed to be 2022-03-06 15:02:11+01:00
2. Your time zone is set correctly on your system.

[Mariusthvdb (Marius)]

Hi Petro,
thanks!

this is what is returned:

and yes, I am on +1 with DST.

Ive written the developer, and hope to get some response soon.
I guess its safe to assume the assumptions, nowhere else in the system is this an issue, and, these data sets are not HA generated, but generated by the external device.

fwiw, one of the other external devices publishes this:

which is exactly (never mind the timing difference here in my screenshots) what my local time on my Mac shows, and what now() in HA shows:

so that should be safe.

[boheme61]

i’ve also tried to get a grip on this “syndrome”, where does it come from, where/what change it, and what to do, if it won’t play “my tune” … i will read your little “investigation” and petro’s explanation, over, and over again, when needed a “solution”, not that i ever think i will understand the “logic” … i tend to look for “workarounds”, thou i wish that a device (which can report whatever timedateTz, producer like) could be “stripped/converted” to system default at integration/reporting time, but seems like various integrations uses various ways

[arrows]

@parautenbach

{{ package.timestamp | timestamp_custom("%d-%m-%y") }}

@finity did you get this timestamp formatting working for 17track?
I am trying to use this format exactly (as you noted earlier in this thread) but my timestamp isn’t changing. Any hints?

[finity]

what is the format of the 17track time value?

a screenshot of the state will be OK or whatever shows the time value you are working with.