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)
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. 
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.
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.
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…
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.
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:
… but what I usually do is just capture $dayOfWeekName at the time of the event
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.
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
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.
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
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.
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:
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.
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?
I assumed a variable called $localTime would show my local time. It was 8 hours off my local time.
Figured it out:
(actualDate, “d”) gave me a number to compare, and (actualDate, “EEEE”) gave me an actual name of day, so I used those. Much easier than I’d feared.
A few days late but I’ve been working on something similar. The formatDateTime kept returning 1970. What I finally realized is groovy/java is expecting the time to be in milliseconds, not seconds. If you multiply the epoch time by 1000, it can then be properly formatted using formatDateTime().
