Hi all,
when I use this template
B1: {{ (as_timestamp(now()) - as_timestamp(state_attr('sensor.verstarker_b1_linkquality', 'last_seen'))) | timestamp_custom(format_string, local_time=True) }}
, I get the error
TypeError: timestamp_custom() got an unexpected keyword argument 'local_time'
Any ideas why and how to overcome it? It works if I just leave it blank for ‚local_time‘ but I think I have time zone issues then.
Thanks!
timestamp_custom(format_string, true)
I’m assuming format_string is a variable you defined elsewhere.
Wow that was fast. That worked. But I didn’t define a variable before. It was inside the template editor.
By now I found out that I have no time zone issues, I have no idea what’s wrong.
This:
{{ as_timestamp(now())| timestamp_custom('%H:%M', true) }}
{{ as_timestamp(state_attr('sensor.verstarker_b1_linkquality', 'last_seen')) | timestamp_custom('%H:%M', true) }}
B1: {{ (as_timestamp(now()) - as_timestamp(state_attr('sensor.verstarker_b1_linkquality', 'last_seen')))| timestamp_custom('%H:%M', true) }}
(‘true’ in the Last line doesn’t change anything)
gives me this:
01:48
01:19
B1: 01:29
After B1 there should just be ‘00:29’, shouldn’t it?
Funny thing:
B1: {{ (as_timestamp(now()) - as_timestamp(now()))| timestamp_custom('%X', true) }}
Gives:
B1: 00:59:59
Got it
timestamp_custom(format_string, local_time=True) converts an UNIX timestamp to its string representation based on a custom format, the use of a local timezone is default. Supports the standard Python time formatting options.UNIX timestamp is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970. Therefore, if used as a function’s argument, it can be substituted with a numeric value (int or float).
The calculation is based on UTC.
But still: adding ‚local‘ to the end doesn’t do it. But what does do it is replacing ‚true‘ with ANY other character(s). As soon as I delete everything after ‘%X’, I get the one hour offset. Weird.
So now I have:
B1: {{ (as_timestamp(now()) - as_timestamp(state_attr('sensor.verstarker_b1_linkquality', 'last_seen'))) | timestamp_custom('%X', a) }}
In case it’s still unclear, the error in your first post is because you mistakenly included local_time= in the second parameter of the timestamp_custom function. You only need to specify a boolean value (true or false).
By default it is true so whether you specify true or omit it, it will convert the timestamp to your local time.
If you set it to false it performs no conversion and displays the timestamp as UTC.
Supposing that all your datetimes are right stored in database as UTC, you can use tz django utility in your template to cast your date to your local time
IE if a datetime is stored as Oct 12, 2017 18:00:00 and i want to convert it to America/La_Paz local time (GMT -4) i can use
Session: start time {{ item.session.started_at|timezone:"America/La_Paz" }}
And in the template will show the local time to America/La_Paz (Oct 12, 2017 14:00:00 in this case)
templates/my_template.html.
@123 I implemented your correction here:
Nevertheless your statement is only true for ‘true’. As soon as there’s anything else than ‘true’, the time’s based on utc+0. So ‘false’ does not give a specific response.
@William88 I am really sorry, but what you are talking about seems to be way above my level of knowledge. Could you maybe give me more information? It gives me errors on the template-editor. It does not understand ‘:’, but even without ‘:’ it says that there’s not a filter ‘timezone’.
——————
So to make things simple, let’s leave out the other information: I live in UTC+2. Why is here one hour offset? Doesn’t seem to fit anything:
Without the timestamp filter I receive ‘minus’ some milliseconds, so works perfectly.
sensor.time gives me the correct time.
EDIT:
So the above mentioned ‘funny thing’ is probably 59:59 because these neg. milliseconds translate into the one minute missing. I wanted to avoid this problem to exclude it as a source and came up with the following:
B1: {{ ((as_timestamp(now()) | timestamp_local | float) - ((as_timestamp(now()))) | timestamp_local | float) | timestamp_local}}
B1: {{ ((as_timestamp(now()) | timestamp_local | float) - ((as_timestamp(now()))) | timestamp_local | float) | timestamp_utc}}
gives:
B1: 1970-01-01 01:00:00
B1: 1970-01-01 00:00:00
Error should be at/around the filter.
Does somebody know where the filter timestamp_local gets its information from?
Is there maybe a mistake in UTC and UTC summer time?
What do you mean by “specific response”?
My timezone offset is -4 hours so when the parameter is false the timestamp is not converted to local time and displayed without the offset (effectively, UTC).
What is your timezone offset? If it’s 0 then using either true or false won’t make a difference. If your timezone offset is a non-zero value then there will be a difference.
@123 see
Replace ‘false’ with any char, results in the same (which is ‘not true’(==utc)).
I live in utc+2(summer time, in winter utc+1), but timestamp_local gives me +1 offset. Please see my previous comment. And don’t mind the complex template.
{{ 120 | timestamp_local }}
gives me 1 hour offset too.
I’m unfamiliar with django. Home Assistant uses Jinja2. What’s the Jinja2 equivalent of the example you posted?
That’s due to how Home Assistant handles/interprets boolean values. For example, 1 and 0 are acceptable substitutes for true and false. The letter a doesn’t represent true so it’s handled as false.
That implies there’s a potential problem with the configuration of Home Assistant’s timezone and/or the configuration of the system clock on the machine hosting Home Assistant. You will need to check both to correct the faulty timezone offset.
@123 sensor.time gives me the correct time. So utc is correct and my time zone. Also just checked the UI-config, where the right zone is entered
Unfortunately that’s insufficient evidence that the offset is being handled correctly throughout the year. timestamp_local works perfectly for me (always) so the fact it doesn’t for you suggests there’s an underlying problem with basic timezone and DST configuration.
Good, now check the host machine’s system clock (i.e. its timezone offset).
You should know that there are numerous existing threads in this community forum where people have reported incorrect reported times and the root cause is always misconfiguration, frequently the system clock (it can get even more complicated if you’re hosting Home Assistant in a virtual machine).
@123
I changed the config manually, tested every template for times that I could find, looked at the log times, restarted. Everything seems to be fine. I use hassOS on the raspberry pi, so I don’t know how the check further the hosts or systems time, sorry.
Until you get that resolved, timestamp_local will continue to report the time with the wrong offset.
Anyway, that’s unrelated to the original question you posted which was about timextamp_custom producing an error message. That was resolved in the second post which identified the cause to be the erroneous inclusion of local_time= in the parameter.
Please consider marking my first post with the Solution tag. It will automatically place a check-mark next to the topic’s title which signals to other users that this topic has been resolved. It helps users find answers to similar questions.
If you need help solving the secondary issue, that your system doesn’t always use the correct timezone offset, I suggest you report it in a separate topic where it will draw a wider audience.
