First, you can convert your timestamp to a date format of your choosing without using a function node; instead, use a Mutate node and the {{formatDate}} Handlebars helper.

In the Mutate node, select "Set a new value". Then, in the Value Template, enter {{formatDate (multiply path.to.the.time.to.[0].convert 1000) 'kk:mm'}}.

{{formatDate}} takes two arguments. The first is the value to format, which is your timestamp. We're including a subhelper in here (the (multiply ...) part) to convert your timestamp from seconds to milliseconds. Note that if your timestamp is already in milliseconds, I recommend keeping the multiply subhelper in place but changing the 1000 to a 1, just to ensure that your timestamp is cast to a number.

The second argument is the Moment.js format string for how you want the date displayed. I believe kk:mm is what you want here based on the example you posted.

To answer your original question, when using a function node, yes, payload must be included in your path (but not in any of the other nodes). But the reason you're getting an error is you're using Handlebars-style variable references in what is a straight Javascript editor. On top of that, you are not converting timeux to a Date object before getting the hours and minutes out of it.

So, you should change this line ...var timeux = payload.path.to.the.time.to.[0].convert * 1000;

... to this (note the missing period before the [0]) ...`var timeux = new Date(payload.path.to.the.time.to[0].convert * 1000);

Now your date methods will work, and then to add goodTime to your payload, just set a new property on the payload object:payload.goodTime = goodTime;

I’m having a bit of trouble formatting my time to the correct local time. For example, my timestamp in my workflow reads: "published_at":Tue Jul 25 2017 17:13:36 GMT-0400, which is correct for EST.

However, when I output this value using mutate and {{formatDate data.published_at 'kk mm'}}, I get: 21 13 , which is correct for UTC time, but I lose the local time in the formatting. What gives? Do I need to take the local offset and do something with that? I’ve read the moment.js docs on this, but it’s clear the entire library is not supported in Losant.

There’s not an easy way to do what you’re looking for; there is, however, a somewhat convoluted way.

See this attached workflow (1.4 KB). We’re using Google’s Time Zone API to get the offset to apply to our current time. Time zone is determined using a latitude and longitude, which we’re defining in our workflow globals. Whether to apply daylight savings time is a function of the current time and that same location. We’re then using those values to calculate a local time, format it, and put the value on our payload using a Mutate Node.

I would recommend only calling the Google API every so often and storing / retrieving those offsets using the Store Value and Get Value nodes. Otherwise, you will have to add an API key to the Google request.

Ah, I see what you did there! Verrry crafty. So it’s possible I would only need to call this workflow at most once a day as the only thing that will change is DST. Thanks for your help!

I still don’t think I fully understand why converting the object to a string strips the local time settings. Because I feel like we’re duplicating some efforts here - clearly Losant already grabs the local time offset (perhaps via user IP?), but it seems there isn’t a way to access it.

The time as you’re seeing it in the debug log is being offset (localized) by your browser, not by Losant. When we deal with timestamps, everything is in UTC. When you, for example, push a virtual button, it’s not sending your browser’s timestamp up with the request. Does that make sense?