that’s utc, typically everything under the hood in HomeAssistant is UTC. That’s actually the exact same time but you’re viewing it from a different timezone. In cacluations, it’ll be treated as the same time. What’s your actual goal here? Is this for display purposes only?
I’m trying to show the time the machine has been running, but because the timestamp is being cut off, it loses the timezone setting (as can be seen in the developer tools). If I store date + time + zone in a datetime field, I would expect it to remain intact, but that doesn;t seem to be the case, only date.time seems to be stored.
Now() contains:2022-02-15 14:24:56.064692+01:00
I store now() in a input_datetime field named dryer_started_datetime’, and display it: 2022-02-15 13:24:56
If it would contain the entire field, I would expect that calculations would show up correct, and that
Now() - input_datetime.washingmachine_started_datetime would be the exact time the machine did run, but it’s one hour off.
If all timestamps are stored in UTC, then why does it calculate one hour difference between these two values that are basically clones ?
Yes, as I explained… 2022-02-15 14:24:56.064692+01:00 is equal to 2022-02-15 13:24:56. They are literally identical, just that the one does not contain the implied UTC timezone.
$now is most likely an object in UTC in nodered, where the set_datetime is not aware of a TZ. It’s just a date storing object and you can treat it like your current timezone or utc.
set_datetime does not know any timezones. It’s timezone agnostic. You must add the timezone itself or set it properly. Assuming that $now() is utc, then just add +00:00. Otherwise, don’t use node red to set a timestamp.
How simple is your automation in node red? It might be worth it to just avoid it with a template sensor if there isn’t much logic.
Yes, as I explained… 2022-02-15 14:24:56.064692+01:00 is equal to 2022-02-15 13:24:56. They are literally identical, just that the one does not contain the implied UTC timezone.
That notation logic is only true for people in a single timezone that do not work with summertime, otherwise it’s only sometimes true.
$now is most likely an object in UTC in nodered, where the set_datetime is not aware of a TZ. It’s just a date storing object and you can treat it like your current timezone or utc.
$now() is a standard JSON function, and if you would put it into your developer tools (as{{ (now()) }} ) it would probably also show you the timestamp including the timezone.
set_datetime does not know any timezones. It’s timezone agnostic. You must add the timezone itself or set it properly. Assuming that $now() is utc, then just add +00:00. Otherwise, don’t use node red to set a timestamp.
What you seem to infer here is timezone ignorant, it simply ignores any timezone and expects all to be the same timezone. Looks like set_datetime is not really setup with the intricacies of time in mind, and therefore not very usefull except for the basics.
How simple is your automation in node red? It might be worth it to just avoid it with a template sensor if there isn’t much logic.
I would like to do this in nodered, since the whole flow is in nodered. I have the running time in a template sensor, but seems I cannot depend on the notation of the starttime.
beside the point, of course UTC will remain the same, but you stated 2022-02-15 14:24:56.064692+01:00 is equal to 2022-02-15 13:24:56. Add 4 months and you’re in a different timezone. That is not what you want to happen, therefore the +/- is an essential part of the timenotation
No… in 4 months if you request now() and DST isn’t applied your local timestamp will be +00:00. If you’re referencing your old timestamp, it still has the +01:00 attached to it so it still knows how to compare them and they will be equal. Well they won’t be equal, because of the 4 month difference, but the time of day will be the same.
You’re encroaching into the confusing aspects of time on computers. This is why everything is always stored as UTC, because you can easily translate that time into your current timezone and ensure you have the correct time.
You may see UTC as useless but it gets around everything you’re describing.
Yes, UTC is the way to go, BUT, everything needs to work the same then, so if I store a UTC field in another field, then the difference between those 2 must be 0. and not 60 minutes because a timezone suddenly matters. Which is exactly what’s happending here.
What you don’t understand is that it’s the exact same time. You’re putting in the local time with a timezone and it’s placing it as UTC into the datetime. It’s that input_datetime’s never have provided a timezone in it’s state that is displayed to the user. That’s just how input_datetimes work.
