Normalize Date and Time

Feature Requests
1

#rant
For the love of god please normalize all date time entites and implement some kind date/time framework for date time calculations.

This is insane. You shouldn’t have to spend 2 days browsing the forum and do trial and error with kind of format the entity have and how to do calculations.
Is a timestamp? is a string? is a date object? do i need it to need to convert it 4 times to be able to calculate the time difference? what kind of Babylonian elder god do i need to sacrifice to?

#endrant

2

Not that complicated, really.

  • Entity states and attributes are always strings
  • To do calculations, you can convert those, via templates, to whether:
    • A timestamp (seconds since 1970-01-01 00:00:00). You can do integer math on those
    • A datetime object. You use timedelta for calculations on those
1 Like
3

Yes very easy, that’s why there are 500 million threads on the forum on how to manage time and dates.
It’s easy for a person with deep knowledge about date and time handling in python. It’s completely gobbledygook for mortals.
I’m a senior developer(20+ years experience) and I hate the way home assistant handle datetime calculations. It’s 2021 soon 2022, not 1993, there is plenty of framework to manage time in a sane way,

I dare to say that time/date-automation is one of the most common automation there is and you still need arcane knowledge how to do them.

4

I don’t get your gripe, then. You know that date & time has always been a pain in all existing frameworks/language.
Python is no different. You have a datetime class. Point.

What are your expectations, exactly?
Or, probably the proper question, what was was the pain point that put you in rant mode?

5

Ex: (pseudo code)
timehelper=10:00:00
timehelper + addminutes(34)

Ex:
datehelper=2022-01-01
datehelper + substractmonths(13)

Ex:
dateandtimehelper = 2022-01-01 01:00:00
dateandtimehelper + adddays(45)
whatmonth = getmonth(dateandtimehelper)

Date time is a hassle if you make it an hassle. Why do you think i rant.

Here is an example of a library that make it sane.
https://arrow.readthedocs.io/en/latest/

6 
{{ ((today_at(states("input_datetime.leaving_time"))) + timedelta(minutes=34)).strftime("%H:%M") }}
{{as_datetime(states("input_datetime.datetime")) + timedelta(days=45) }}
{{(as_datetime(states("input_datetime.datetime")) + timedelta(days=45)).month }}

I agree there is gap regarding months. Support for months/years is lacking in timedelta (or a datedelta). Good idea for a PR :slight_smile:

7

You’re ranting about old posts. Everything you want exists but you’re stumbling on old posts that are from a while ago. You can use datetime objects for everything and you never need to convert to seconds anymore. Been this way for a few versions, koying is pointing them out in his post. If you have idea’s on how to simplify this:

{{ today_at("07:00") > now() }}

I’m all ears. Back in the day this was a pita and you’re running into those posts.

{{ today_at("10:00") + timedelta(minutes=34) }}

subtracting months is near impossible for any system. Sorry. You can thank the Gregorian calendar for making each month a different length. You can however, guesstimate.

It is a bit long, might be a good idea for us to make as_local allow iso timestrings as an input.

{{ '2022-01-01' | as_datetime | as_local - timedelta(days=13 * 30) }}

{{ ('2022-01-01 01:00:00' | as_datetime | as_local + timedelta(days=45)).month }}

You might just want to brush up on the template methods too. People on these forums outside a small handful don’t understand dates so they throw anything they can at a wall until it gets close to what they want.

Anyways, hope this helps.

1 Like
8

Years is easy, just 365 * #, month will always be a pain in the ass because it has to be aware of the month you’re in. Timedelta has no concept of month you’re in. So we’d have to extend datetime objects and timedeltas objects and most likely override the + and - operations on those objects. But I don’t know of a single software language that does months.

9

Not too difficult, but cumbersome to calculate for any non dev.
It’s about the same story as 'today_at". It was already possible to do before it, but painful.

10

It’s easy with datetimes, it would be easy with a method too. I’m referring to adding it to timedelta which would make the most sense.

1 Like
11

I will open a prospective Arch discussion about that…

12

Leap years?

13 
{% set date = as_datetime("2022-01-15") %}
{% set submonths = 13 %}
{{ date.replace(year=date.year - submonths//12).replace(month= [12, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12][date.month - submonths%12]) }}

Not overly complicated but convoluted :wink:

14

Yes, I know. That’s exactly what I’m referring to about using it with datetimes.

However, make a timedelta object with months that outputs days (Because timedeltas do that) without adding a date to it. Just a simple {{ timedelta(months=1) }} that would output the proper number of days if you did this {{ timedelta(months=1).days }}. Does a timedelta with months output 28 days? 29 days? 30 days? 31 days?

So again, the calculation is very easy when you have a moment in time. It’s impossible without a moment in time.

Adding any separate object or method would also be just as challenging unless we made the method accept the datetime. That means we would be forced to make it in a non-jinja way, i.e. addmonth(datetime, months) or timecalc(datetime, operation, months=3). This is where it starts to get ugly and people who don’t use code already have issues with arguments. This is why I don’t think we will see anything come out of this.

The only possible solution that I can see is if we do something generic. We override the def __add__(self, other) and __sub__(self, other) methods in the datetime object and the timedelta object. Alone, when you use months in timedelta, it will always output the average number of days in a month. However, under the hood it stores the number of input months. Then when you use it in a math operation, the datetime or timedelta object checks the other object for months and performs the calculation while simultaneously overwriting number of days in the timedelta object.

15

I agree with the OP, I’m new to HA and not a programmer (hobby or otherwise) and terrible at math. In HS I can use $time . and ( $$time for spoken times)… it takes 5 seconds tops.

I’m almost ashamed to say it took me 2+ hours to figure out how to insert the same time into a tts message in HA.

16

It’s just {{ now().time() }} That’s pretty easy to read, you just didn’t know the syntax. How would you propose to make that’s easier?

EDIT: Keep in mind that jinja will not allow $ or characters like your example, so that’s not an option.

17

I also what to clarify, I’m not against any changes. I’ll put in anything that makes time easier in jinja as long as the main devs accept my PR.

18

As it pertains to UI functionality (since this is the area I prefer as a non-programmer), perhaps a time/date drop down option with offered selections (much like the icon picker), Or a Time/Date Format helper (like there are in some areas for picking devices and identities, etc)

For me, UI tools and functions make building things in HA more pleasant. It’s my understanding the HA devs have really created a lot of UI functionality in the last few years, which makes it far more approachable by the average person IMO.

19

And how would the dropdown help when making templates?

20

The only reason I had to use a template was because the UI required it.