As_timestamp(now()) - strange behaviour - time not calculating properly with timezone offset

Installation Home Assistant OS
1

Hi. This is a weird one but somebody might know how to help. I’m running Hass.io on a Pi 3 B+. HA v0.92.2. aarch64. I’m in Sydney, Australia where the timezone is GMT +10.
I have a value template that calculates a fortnightly pattern (helps me with a sensor to put the correct bin out). But it is failing…
{{ ((as_timestamp(now()) - as_timestamp('2019-05-01 00:00:00'))) / 86400 |int % 14 < 1 }} should be true. The 1st May 2019 was 14 days ago. But I get false on my system. My timezone in configuration.yaml has
time_zone: Australia/NSW
@DavidFW1960 who created the code, and is in the same timezone as me, gets true when he tests it in template editor. It’s as if on my system as_timestamp is using a the GMT value and not GMT +10. The only way I can get it to work is to add 36000 as a clumsy way of providing a timezone offset. Any ideas on why this does not work for me; especially as another user in the same timezone gets the correct result.

image
image1448×274 34.4 KB

1 Like
2

What’s the HassOS version? Is that current/up-to-date?

image
image841×457 21.2 KB

3

I believe it to be the latest. Mine says Version: 163. Host system is HassOS 2.11

4

Current HassOS is 2.12 - Perhaps try an update to that.

Perhaps @petro or @123 can help

1 Like
5

gotta add timezone otherwise it will be 10 hours off because it will assume UTC.

{{ ((as_timestamp(now()) - as_timestamp('2019-05-01 00:00:00+10:00'))) / 86400 |int % 14 < 1 }}

EDIT: I Just checked this on my system and w/o timezone it assumes local. Something’s wrong with your system time.

1 Like
6

Thank you Petro. I wonder why David’s works then? I suppose my calculations will be off by an hour when Day Light Saving gets applied here in NSW, Australia.

7

Must be. How to find my bug…? When David and I were running comparrisons our epoch unix times were about the same.

8

Ah, you gotta make sure the python version of your timezone is using DLS. If not, find the name of the one that does and set that in your configuration.yaml timezone section.

For example, I’m EST, but that doesn’t use DLS. So I have to use America/New_York

Maybe you are Australia/Sydney according to the wiki page

9

I think mine acknowledges DLS but I’d rather find what is wrong with my system so I don’t have to include +10. I’m also running DuckDNS and NGINX SSL Proxy (in case that matters somehow)

10

Yes, this will fix it. Find the correct TZ to put in your configuration.yaml for home assistant and it should fix your problem.

1 Like
11

@DavidFW1960 , what are you on? I suppose I’ll try Australia/Sydney

12

I only said that because the other names according to wiki were depreciated and they redirected to Australia/Sydney

13

Just noticed that too. I’ll give it a whirl

14

Back in the game! Thanks so much mate!!!

15

Nice, glad it works. Remind me again in 6 months when DLS ends… :rofl: hopefully it changes

16

That was my first thought as well.

17 
my_timezone: Australia/Sydney
18

Yes it works perfectly year round for me so if @Milster uses same TZ he will be sweet.

19

Definitely sticking with Australia/Sydney. I wonder when the other one became deprecated. Anyway, appreciate your help gents! Have a great day!

2 Likes
20

@DavidFW1960 and @petro I had the same failure this morning with (for today’s date)…
{{ ((as_timestamp(now()) - as_timestamp('2019-05-02 00:00:00'))) / 86400 |int % 14 < 1 }}
I’m just waiting for 10am to tick over where I suspect I will get true as the response.
As a matter of logic can I ask… As a hypothetical lets say I waited until midnight tonight and entered this…
{{ (as_timestamp(now()) }}
and
{{ as_timestamp('2019-05-17 00:00:00') }}
They would return different numbers wouldn’t they? Is that correct? The second value would be midnight in Greenwich, ie. 10hrs earlier?