That’s a good one
Thank you so much for your assistance. However, sometimes I do not understand the do’s and dont’s of the template editor. It fails on this one:
Thank you so much. You’ve yet again solved one of the great syntax mysteries.
( I wonder what pleasure the creator had in making things so complex and completely unlogical)
finity: could you have a look at “Chicken Eggs!” ??? - I think it needs your time wizzardry skills and I think I’m going to have to read this thread twice a day and practice for a month to get my head round this.
I don’t think it needs Phil’s “Sun Enhancement” just subtract one time from another, subtract a few more hours and then output as minutes.
Also I’m not sure that you noticed but I made the first posts able to be fully copied into the template editor so you can copy them over and play with them to get different results.
In milliseconds - 1544817447000 (which is another can of worms).
Yes, the time stated should be the local time and the bit on the end simply tells you the relationship of that time string to UTC.
Coming a bit late to this but the best way I found of visualizing this, is to think of time & date as a number. Wherever you are on the globe, everyone is at the same instantaneous number - the UNIX timestamp - UTC.
The number (or TZ) on the end of the string representation, tells you what that number string is relative to UTC (or GMT or Zulu time) where a minus is behind (midday is later) and plus is ahead (midday is earlier) than if you were on UTC.
So if your timezone is -5, you are 5 hours behind so when UTC is 19:00, local time to you is 14:00 but in ISO format that is 14:00-05:00 not 19:00-05:00
Without a timezone, the time & date string is always assumed to be local.
Would anyone have a way of explaining how to use the input_datetime component for comparison?
Specifically just the has_date: false/has_time: true usage.
When trying to use the timestamp attribute in this configuration, it only produces the number of seconds from midnight of the current day when used in templates which doesn’t play well with as_timestamp’s use of the Unix starting point.
I’m trying to use the time entry at the input_datetime component in the frontend to trigger an action everyday at that time.
unfortunately because of the nature of the timestamp you won’t be able to use as_timestamp() with an input_datetime that doesn’t have the date part.
As far as I know…
You would have to figure out a way to add the date to it. But if you are going to that trouble it would be easier to just use an input_datetime that has both date and time and be done with it.
However, if I understand your use case you should just be able to use the state of the time-only input_datetime and do a compare to the starting time as a string.
Something like (using one of my time only entities):
It’s a Thread that I, and many others, refer to on ‘time’
Your will also see people’s questions being answered with a further hint - “if you need to addapt this, consult finity’s EPIC time thread” It’s number 2 on the list when you enter ‘EPIC’ into the search.
@bwze you need to be an admin to lock a thread, there’s very few of them about and anyway that would stop the likes of @baz123 from posting a clarification like the one above (in looking I see I’m also guilty of polluting this thread, my apologies )
Crap! that sucks! I thought for sure that with a word like EPIC in the title it would be number 1. I mean, mine is in ALL CAPS for cryin’ out loud. While the other one is in all lower case. what is this some kind of plebian conspiracy?!
Did you look into your HA log when pasting it into Template editor? Mine says
TypeError: unsupported operand type(s) for +: ‘datetime.datetime’ and ‘datetime.datetime’
but in fact these errors are not always exactly what they say.
May I ask you why do you want that particular operation to work? Here is some info that possibly explains something (look for Supported operations).