Bug? Global variables with type = time

[gustvao]

I have a simple piston that turns on my lights if certain conditions are met + TIME is between 2 global variables (variables type = time). Piston code -> 49neg

The thing is, when the piston checks the is between condition, it returns false because 1 of the global variables has the year 1970...

Comparison 66708334 is_between 1970-01-01T16:00:00.000Z .. 2017-07-10T01:00:00.000Z = false (14ms)

Those are the values, in local time of my global variables used with this piston:

Any ideas of why the global variable gets set with the year 1970 and how to fix this?

Tks vm and congrats for the project, it is amazing!!

[gustvao]

more info...

I found out that if I setup the global variable by time, it defaults to 1970 (which is start of unix time counter)... so obviously I tried starting with DATETIME and then switched only to type TIME before clicking save and it worked..

so in logs the comparison was considering the correct datetimes but was still defaulting to false...

So i went to conver the unix time of the example to current date and, to my surprise:

So when using time comparison, for some reason you guys create the date with some reference of unix time (in this case 1972ish) where the TIME should get the reference from now, as I believe.

Can you pls help me fix this? Should be a simple fix..

Tks and let me know if I can help Gustavo

[ady624]

Problem was with variables set via the UI - there is no casting performed on them at set time (pistons cast them into their proper type while saving them, the UI does not) - enforcing casting on read fixed the problem, will look for a way to cast them at write time - casting is a function of the piston code, setting global variables does not involve any piston, therefore the cast function is not easily available at that time.

Fixed in v0.2.0d3, thank you for pointing it out.

[gustvao]

@ady624 still not working..

now both globals are set to unix time on comparison but all them (globals and current TIME) are defaulting to 1970ish..

still not working as it should

Comparison 86257759 is_not_between 9000000 .. 36000000 = true (10ms)

[gustvao]

more info:

now my time global variables get changed to a fixed value all the time the piston run..

so regardless of the value I put in my global variables, they always come back to the values below.. very odd

[ady624]

the time variable is a timestamp modded to 86400000 max. 9000000 means 2:30am, 36000000 means 10am, and 86257759 is about 11:57pm - all these are UTC

[gustvao]

@ady624 I dont understand how you convert 36000000 to 10am UTC, I am using time conversor like this https://www.epochconverter.com/ and they all return 4pm.

The thing is, even your conversion being correct, the dates of those timestamps are in different years, so the comparison by time wont work because they are not in the "same era".

Anyways, I see 2 issues still that are still making pistons not work correctly with global variables:

1) the comparison is still returning the wrong result for in between comparisons... from what you mention, 11h57 was my current time, but you said it was in UTC. Maybe TIME variable is not considering timezone?

2) after you made the last commit, my global variables get RESET to "random" values after the piston runs. This is super odd.

So I set them up as:

and after the piston runs it changes the global variables (despite I never instructed the piston to do so) to:

Any ideas?

P.S.: I am in Brazil using BRT time

[gustvao]

for issue number 2 I understood what is going on, you are converting my BRT global variables to UTC global variables..

[gustvao]

@ady624 I understood what is going on, here is the explanation (I still think a fix must be done)

So your comparison is working fine, the issue is that the PISTON changes the value of the TIME GLOBAL VARIABLE after it is run for the first time, I guess?

And it converts the TIME GLOBAL variable that I put in my current BRT timezone to UTC, therefore, causing unexpected behaviours.

So what I had to do to make it work properly was:

If I needed 10AM BRT, for exemple, I had to put in TIME GLOBAL VARIABLE 7AM, because 7AM BRT means 10AM UTC and when the comparison is made, the SYSTEM TIME VARIABLE is in UTC but actually reflects atual BRT time. So if now is 10AM BRT, SYSTEM TIME VARIABLE in comparison is 10AM UTC...

It is a bit confusing, let me know if you have any questions.

My suggestion is to make it somehow you SELECT the TIMEZONE when you create the GLOBAL VARIABLE or always assume it is your LOCAL TIMEZONE.

Let me know if you need any other info.

[gustvao]

@ady624 should you reopen this one?

[ady624]

I need to look into this closer. Got any steps to reproduce the issue?