Sorry, my description of changes above seemed complicated. Here is a piston where this is implemented. You need to define the two global variables and then just use them in your calling piston as described above.
Convert UTC / Epoch Time to Human Time
Mebejedi
#22
Two things:
1: What do you use to determine if DST is on or off? Could I steal your piston for that?
2: Using another piston to convert epoch to human didn’t work, because apparently global variables don’t update quick enough. Sooooo…I had to put it in my Where Is Everybody piston. Luckily, I’m getting good at loops, so I only had to put it in once, and loop each of the times through it. This piston’s a monster now, but it works!
guxdude
#23
I saw you post your problem with global variables. That’s too bad it didn’t work. I first had a piston that only ran twice a year but webCoRE had a problem with scheduling things more than three months in the future. Based on input from @WCmore, I changed to this method which only runs once a week. Wont be fully tested until next March but looks solid to me.
WCmore
#24
Lookin’ good, @guxdude…
My only thought is perhaps delaying that time a tiny bit… Spring forward means that 2AM jumps to 3AM… (Thereby bypassing 2:30 AM once a year)
I cannot say with confidence that your current piston will fire reliably on that day.
(Mine runs at 3:05AM to insure that the data is up-to-date)
Actually, now that I think about it, even as early as 12:01AM might suffice. (as long as SmartThings internal clock has jumped to a new day, the results should return accurately)
guxdude
#25
I thought spring forward went 1 am to 2 am and fall back went 2 am to 1 am. I’ll have to look that up.
UPDATE: As usual, @WCmore is correct. I will have to update my piston to 3:30 am. 
Mebejedi
#26
Actually, it wasn’t too bad once I realized I could loop the epoch converter. Now everything’s all in one loop, all nice and happy.
I notice you changed the super global variable @@DST to just @DST. Is that correct? Is my variable still correct if I make that change?
And yes…@WCmore is absolutely the man…definitely knows his stuff.
guxdude
#27
Based on @wcmore experience and the change to weekly update vs twice a year, I shifted to the standard global variable. The important thing is that they are consistent. As long as you use the same in both places you should be good but the @DST should be more reliable.
WCmore
#28
Thank you all for the kind words… but it’s important to note that I would not be able to do what I do if the people before me did not lay the groundwork…
I won’t let it go to my head…
Mebejedi
#29
I realized that if someone (say, my son) has been home since yesterday, the time given of his arrival would be misleading. Is there a quick&dirty way to evaluate the “actualDate” to see if it was yesterday? Then I could tell my piston to add “since yesterday at” to the final message.
WCmore
#30
In reference to line 188:
I think you could do the same math on $now, and then subtract {actualDate}… If the results are more than 86,400 seconds, then it happened over 24 hours ago. (You can also divide that answer by 86,400 to find out how many days ago it was)
For example, IF {actualDate} captures seconds, then:
($now converted into seconds) - {actualDate} = 215,136 seconds / 86,400 = 2.49 days
Occasionally, I may code:
- If the time is less than one day, then report in hours…
- If the time is more than one day, then report in days…
… but what I usually do is just capture $dayOfWeekName at the time of the event
Mebejedi
#31
That would mean four more Global Variables… 
They’re really starting to stack up now. Too bad they can’t be strings. I’ll try to figure out the math instead. Fewer lines to code.
Hey, there’s a $localNow variable, but it’s off by 8 hours!!! I wonder if there’s a way to set my timezone in Webcore? Would make things a lot simpler.
$utc is correct, though. Weird.
Mebejedi
#32
So, I got this to work. I’ll probably go back at some point and try to determine how many days, or from which day, someone has still at home (My son likes to be in his room during vacation), but it’s satisfactory for now. I also set up a second switch so it’ll just give me locations.
“Alexa, where is everyone/everybody” = locations
“Alexa, where is everyone/everybody since” - locations and times
WCmore
#33
I often make my globals a string, and then save the time and text to that single global.
IE: Set variable {susLoc} = "Susie came home at "$time" on "$dayOfWeekName
The only downfall with this method is you cannot do math directly with the global.
WCmore
#35
True, but you can dump them in a normal string, and then pick it apart later, if desired.
IE, if the global string {susLoc} is:
12:42 AM on Saturday, Susie came home
Then the time can be called with this expression:
…and the first 3 letters of the day of week can be called with this:
Essentially, less globals = (a bit) more coding
Mebejedi
#36
Now THAT, sir, is AWESOME.
That said, I kinda hate you right now, 'cause now there’s a part of me that wants to go back and redo the Globals for this PERFECTLY FINE WORKING PISTON!!! . 
I’m saving those directions for later…
[EDIT] Since the length of each day’s name is different, couldn’t you pad the shorter days with spaces, grab whichever day from the Global, and have ES speak the name? Then you could put it into a loop like a string list.
WCmore
#37
If you pad, it’s probably better to use periods… (spaces get “eaten” under many conditions)
You can also parse by adding a unique character after the $dayOfWeekName, and then using “indexOf” to determine what position it is in.
Or in this case, we can use “day,” to determine the length of the word… as seen here:
Here is the same code working on a different day:
WCmore
#38
I don’t know if this will answer your question, but the Expression:
formatDateTime($now, "z")
returns your current timezone (abbreviated as a 3 letter string)
Here is an example of it in use.
guxdude
#40
Appears your time zone is PST according to the pictures you posted and that is 8 hours different than UTC. Everything looks right. What was the issue?