Adding 15 minutes to time now

What am I missing?
Why does this give me the time in 1 hour an 15 minutes?

{{ (now().strftime("%s") | int + (15*60)) | timestamp_custom("%H:%M")}}

1 Like

Try…

"{{ states('sensor.time') == (((state_attr('input_datetime.bedroom_alarm_clock_time' , 'timestamp')) + (15 * 60))|timestamp_custom('%H:%M', false)) }}"

(that code is from my alarm clock, so adjust for your own sensors or ‘now()’ as appropriate)

The ‘false’ at the end is the fix, but I don’t quite understand why if I’m honest because the way the docs explain it it should be true, which would mean leaving it out should be fine too, but there we are.

Hope this helps.

2 Likes

Perfect.
Thank you (again).

1 Like

@klogg

timestamp("%H:%M") will return local time.
timestamp("%H:%M", true) will return local time.
timestamp("%H:%M", false) will return utc time.

EDIT: To clarify, local time is the time in your timezone. UTC is the universal time coordinate. It’s the time zone for england without daylight savings applied.

3 Likes

Hence the confusion. I am on UK time, what with being in the UK, so true / false and nothing should all result in local time for me.

But only false works out correctly.

And given that my ‘sensor.time’ is correct at local time, and my input_datetime is set to the local time I want the alarm to go off, true/nothing should be the correct template.

Thus, that boolean is pretty misleading if you ask me :slightly_smiling_face:

Not sure why that is. What is your timezone? GMT? Maybe daylight savings is incorrectly applied in your timezone?

Well, we’re currently on BST (British Summer Time), but this issue actually occurred for me last winter when we were on GMT before I worked out to add the false. I haven’t had to change it, false works all year round.

1 Like

… My presumption (and it’s a big presumption) is that all time calculations are done in utc and then converted to local time, and something to do with that process means that if you have true/nothing the calculations will be off, so you basically have to include false regardless of your timezone.

If that is the case then false should be the default really, but I guess that method is imported and works correctly in other environments.

No clue, I’d have to play around. All my experience with the time in templates has been helping people here. I do all of my timed stuff in appdaemon. To be quite honest, I can’t believe that HA hasn’t come up with a solution to these time issues. There are so many. I remember a month back, @pnbruckner and sounded like broken records in regards to using now() inside template sensors.

Starting at the top, %s apparently returns an equivalent timestamp. I would do it this way instead:

now().timestamp()

or even:

as_timestamp(now())

The only difference seem to be that using %s returns an integer (i.e., with no “microseconds” after the decimal.)

Note that a timestamp is always UTC (i.e., it’s defined as the number of seconds since the Unix Epoch, which is January 1, 1970, 00:00:00 UTC.) So, if you convert either a local time (e.g., now()), or a UTC time (e.g., utcnow()) to a timestamp, it doesn’t matter, you’ll get the same answer.

That’s probably not “news”, but figured I’d mention it just in case. :slight_smile:

Now, getting back to the original questions, the answers are, 1) you probably have your timezone set incorrectly in either HA or the OS or both, and 2) it doesn’t.

To check, try this in the template editor:

{{ now().strftime("%s") }}
{{ now().timestamp() }}

They should return the same result (well, within a few milliseconds given they don’t actually get evaluated at exactly the same time.) If they give significantly different results (like, say, 60*60), then you have your timezone set incorrectly somewhere.

That’s not the problem, the problem is when you pipe the output of that to timestamp_custom it adds an hour for no reason if you don’t expressly set the false flag.

Sorry to disagree, but that’s not true. E.g., this works just fine for me:

You must be magic :wink:

Hmm, interesting…

So the timestamp and as_timestamp functions give the same, correct results. But strftime w/ %s only gives the correct result when the time is in the local timezone (and both HA and the OS agree on the timezone.)

I think I stick with my original conclusions. At the very least, I stick with the “don’t use strftime(’%s’), but use timestamp or as_timestamp instead” recommendation.

FWIW: https://stackoverflow.com/questions/11743019/convert-python-datetime-to-epoch-with-strftime

2 Likes

Thanks, was tearing my hair out until I found this!

1 Like