Cannot convert UTC code into the correct date (Biggest Problem), and cannot pull code correctly from [device:since] (Smaller problem - or no problem if I can’t solve UTC problem.)
2) What is the expected behaviour?
I created a piston that uses Life360 to tell me where my family members are, and it works well. That said, I noticed Life360 has a “since” setting, which I’m trying to incorporate (“Derek has been at Grandma’s since 4:36”)
3) What is happening/not happening?
Unfortunately, the “since” data is in UTC, and I’ve tried every possible combination of variables, strings, and datetime codes to get “1574987768” to equal “Thursday, November 28th 2019, 4:36”. On https://www.epochconverter.com/ , I can get “1574987768” and “1574987768000” (3 added zeroes to get the full 13-digit format) to get this date:
I’ve located several threads with bits and pieces of this puzzle, but I still haven’t figured the correct formatting.
**4) Post a Green Snapshot of the piston![image|45x37]
This is just a generic piston I came up with to test all the different possibilities. I posted the regular screenshot to show some of the data I’ve been receiving.
Here’s the actual piston, but it’s still a work in progress while I try to figure this out. If I can’t, I’ll just go back to an earlier piston that just provides the location.
Not sure exactly what you are trying to do but did a quick search and came up with this conversion. This works for Pacific Standard Time. Will need to use the appropriate offset depending on time zone/DST for the full conversion.
(Sorry for the poor pic, best I can do on my iPad)
Well, I appreciate the effort - especially at 1:00 in the morning - but it’s not giving the minutes (should be 4:36). It’s amazing that such a thing is so difficult to do in Webcore.
And it appears my date formatting is different. (Where’s that setting at?)
When it does say the time, it says “four oh oh, oh oh PST”. I just wanted “four thirty-six PM” I know @WCmore uses some code to transcode the minutes of current time to “o’clock” and “oh 5”, but I wouldn’t know how to apply that to this variable. I guess I’ll just stay with the “arriving” and “leaving” piston.
@WCmore thank you for this. I have a piston where this has been bugging me. I combined your logic with something else you taught me to come up with this expression.
Only a true programmer can relate to this… I often find myself unwinding after a long day by doing the same… It is a very effective way to “clear the cobwebs”… LOL
Bonus points for finding a partner who is OK with this…
I’m afraid it’s still not working. The piston is focusing on today’s date (even though my son has been home sick for 2 days), and the times are wrong. I did get this error for the DST line, but I don’t know if it’s the problem.
I’m about to walk out the door, but I couldn’t help but notice this error:
Global variables are not created or set at the top of pistons. (please delete that line)
Instead, you want to create global variables by:
Going into ‘Edit’ mode for any piston
Click on “+ add a new global variable” found in the bottom right column:
Also, normally globals have only a single @ at the beginning… Only use two @@ if you need to span instances… but in that case, don’t use it with data that changes often.
In other words, 99% of all globals should only have a single @.
That’s what was in guxdude’s code. I’d never seen anything like that before, and it forced me to create a variable. I figured he probably had a global variable with that name, but wasn’t sure.
Double @@ are “SuperGlobals Variables”, but I have found them to be unreliable as compared to ‘regular’ globals. They do occasionally have a use, but I only use them extremely rarely… and only with data that does not change.
If you are curious, here is the logic behind my reasoning. (Cliff Note version: They don’t always update properly)
Sorry, @@DST is a Boolean. That is why I can use it in the ternary operator. I created a piston that changes it on the second Sunday in March and first Sunday in November. Didn’t need to be a super global at this point but I figured it would change rarely enough to be ok.
Another question…I’ve still got your UTC>Human piston, because a part of me won’t give up on making this work (your piston works, just not within mine). I’ve tried storing the UTC time as a global variable to send over the the UTC piston, do a conversion, and send the result back to my WhereIsEverybody piston (because I’m loathe to put all that coding for all 4 devices), but apparently I can’t create the global variable as a LongNumber variable. Is there any other way this might be possible?
Great idea. You can try just using an integer. There might be enough precision I just used long because that was what you had. Not sure what the precision of the global integer is. Separating the conversion makes sense. You would just need to define a global integer @epochDate and string @stringDate. Use as
Set variable @epochDate=inputDate
Call piston ‘Convert Date’
Set variable outputDate=@stringDate
For testing I would change @@DST to a local variable
Boolean DST=false
Then replace the @@DST with DST. Just be sure the DST definition is before it is used. Or even simpler, just hard code DSToffset=-8 for now.
Also, be sure to replace EpochDate and stringDate with your global versions in every place they show up. Delete the local variables to avoid confusion.
Let me know if you have any more questions. Happy to help.