Relative_time for the future

Development
1

Hi all,

I was thinking something like relative_time would be useful for things like timers if it could use a future datetime.

It doesn’t look too hard to code, and I was thinking of submitting a PR

My question is, should I change the behavior of relative_time to allow future datetimes (I’m thinking probably not)?

Or should I create a relative_time_until which accepts only future datetimes?

Or perhaps just a relative_time_diff which doesn’t care?

For the first option, the reason I’m considering it is because is because I don’t know how often the return value is ever actually checked. And it is kind of a misleading function name (relative_age or relative_time_since would probably have been better choices).

Thanks in advance for your input….

1 Like
2

Something alike already exists. When you have a sensor with a time in the state and device_class ‘timestamp’ it will show relative to the future as well.
image

image

3

They are talking about the filter, not an entity.

I always wondered about the arbitrary requirement for past only and suspect if you create a PR for the existing relative_time filter to support future times it would be accepted and be a great addition.

1 Like
4

It looks like someone copied and pasted some functions from Django, which might be where the requirement come from.

1 Like
5

Upon further reflection, I can see a reason for splitting it into 2.

If you’re using relative_time to tell how much time is left on a timer, you’d probably wouldn’t want it to return a time if the timer expired.

6

Or you can modify relative_time() to accept a second parameter allowing the user to specify its behavior:

  • past (default; to maintain compatibility)
  • future
  • both
1 Like
7

I thought about that too….

I don’t really see a use case for both, though.

8

Well, I submitted a PR, but it looks like there’s a backlog on approval.

9

Would you mind giving us a link to the PR?

10

PR link

1 Like
11

In the meantime, here’s a template workaround:

{% set current_time = now() %}
{% set future_time = as_local(as_datetime(states("sensor.530_rt_retour_Sophia"))) %}
{% set time_distance = future_time - current_time %}
In {{ relative_time(current_time - time_distance) }}

This achieves the same result by simply negating the future time into the past by the same “distance”.

10 Likes
12

Should I rebase and resubmit this?

1 Like
13

I knocked up some macros to try and do this in one go Handy Time

Work like this:

{%- from 'handy_time.jinja' import smart_time -%}
{%- set a = now() - timedelta(days=5) %}
{{ smart_time(a) }}
{%- set a = now() - timedelta(hours=5, seconds=55) %}
{{ smart_time(a) }}
{%- set a = now() + timedelta(hours=5, seconds=55) %}
{{ smart_time(a) }}
{%- set a = now() + timedelta(days=100) %}
{{ smart_time(a) }}
{%- set a = now() - timedelta(days=100) %}
{{ smart_time(a) }}

5d ago
5h 30s ago
in 5h 1m
in 3 months
3 months ago
14

I’ve opened a new pull request for this, since the other one went stale and was closed.

2 Likes
15

Bump. Anyone? I really don’t want to have to wait another year for this.

1 Like