Convert UTC / Epoch Time to Human Time

#10

Nice conversion into an Expression, @guxdude… :+1:

#11

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… :grin:

#12

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.

DST%20error
DST error.jpg766×492 109 KB

Here’s the “final” piston, though without correct times, I can’t use it. I’ll post the top of the non-anonymized piston to show the outputs.

Where%20is%20everybody%20Recode%205B%20Still%20wrong%20date-time%20non-anon%20TOP
Where is everybody Recode 5B Still wrong date-time non-anon TOP.png1150×443 25.4 KB

Where%20is%20everybody%20Recode%205B%20Still%20wrong%20date-time
Where is everybody Recode 5B Still wrong date-time.png1178×2425 332 KB

Anyways, this piston is becoming a beast…so I’ll just go back to announcing locations without time.

#13

I’m about to walk out the door, but I couldn’t help but notice this error:

pic

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:

pic

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 @.

#14

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.

#15

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)

Using a single @ global is the way to go… :+1:

#16

@guxdude, can you elaborate a bit for @Mebejedi’s benefit about the contents of your @@DST?

It’s an integer that changes twice a year, right?

#17

Oh, that would make sense. I was wondering how he accounted for that. I assumed it was a system variable.

#18

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.

#19

What would you use the DST Superglobal for?

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?

#20

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.

#21

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.

image
86432A4B-5561-4DC6-848B-A54DF9703532.png2048×1536 491 KB

#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!

#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.

image
0F78A4BE-069C-4118-9733-4657DDC965B8.png2048×1536 330 KB

#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)

#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. :slight_smile:

#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?

WIE%2010%20DST

And yes…@WCmore is absolutely the man…definitely knows his stuff.

#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.

#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…

bighead

#29

Since%20Yesterday
Since Yesterday.png1087×563 28.7 KB

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.