Convert Epoch time to human readable format

[Iain MacMillan]

I am trying to convert an EPOCH timestamp into its human readable format (string or object).

I am calling the object "time" from Darkskys API    {payload: msg.payload.daily.data[0].time}; and would like a function to return that value in a format that is not epoch so I can display it.

I am fine with doing the conversation to different format strings/objects with day/month/time etc.

My problem is getting the date stamp for that time, not time "now".

Have tried the various momentjs nodes, but they don't seem to be for this.

All the examples I see lead me down the path of  creating a "date now".  Whereas what I want is more a conversion.

I see that node-red debug lets you click on the value and see it in the debug in human readable format, but it defaults to the long number.

The annoying thing is that I know the answer is here somewhere as I had it working from an example from this forum a few weeks back. And even got it working momentarily at some point this weekend.

Thanks 

[Nick O'Leary]

Hi Iain,

with a Function node you can create a Date object from that timestamp, and then use one of methods available on that object to get a human-readable date. For example:

    var date = new Date(msg.payload.daily.data[0].time);

    msg.payload = date.toUTCString();

    return msg;

Here's a list of the available methods on Date objects: https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Date

moment.js provides more flexibility in the format it generates, but you can go a long with with the built-in Date object.

Nick

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+unsubscribe@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/f444ffc7-3c56-4c58-a7b2-403a2919ddf3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Iain MacMillan]

Hi Nick,

Thanks for your help. I think i am missing something obvious here. I tried your suggestions but the date they return is 1970..

I have attached a couple of screenshots, the function node you suggested outputs to the 3rd debug down in the list. Any ideas on converting it to the date shown on the debug node above?

On Monday, 22 May 2017 10:16:27 UTC+1, Nick O'Leary wrote:

Hi Iain,

with a Function node you can create a Date object from that timestamp, and then use one of methods available on that object to get a human-readable date. For example:

    var date = new Date(msg.payload.daily.data[0].time);

    msg.payload = date.toUTCString();

    return msg;

Here's a list of the available methods on Date objects: https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Date

moment.js provides more flexibility in the format it generates, but you can go a long with with the built-in Date object.

Nick

On 22 May 2017 at 10:12, Iain MacMillan <macmill...@gmail.com> wrote:

I am trying to convert an EPOCH timestamp into its human readable format (string or object).

I am calling the object "time" from Darkskys API    {payload: msg.payload.daily.data[0].time}; and would like a function to return that value in a format that is not epoch so I can display it.

I am fine with doing the conversation to different format strings/objects with day/month/time etc.

My problem is getting the date stamp for that time, not time "now".

Have tried the various momentjs nodes, but they don't seem to be for this.

All the examples I see lead me down the path of  creating a "date now".  Whereas what I want is more a conversion.

I see that node-red debug lets you click on the value and see it in the debug in human readable format, but it defaults to the long number.

The annoying thing is that I know the answer is here somewhere as I had it working from an example from this forum a few weeks back. And even got it working momentarily at some point this weekend.

Thanks 

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.

To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.

[Nick O'Leary]

Ah ok - multiple the epoch time by 1000 to go from seconds to milliseconds  before passing to the Date function.

Nick

To unsubscribe from this group and stop receiving emails from it, send an email to node-red+unsubscribe@googlegroups.com.

To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.

To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/c33ce4e5-66d5-4272-b91b-673704063c33%40googlegroups.com.

[Iain MacMillan]

Sooo simple when you know how !!

Thanks a million Nick. BTW are you aware of any nodes that can achieve this within the palette or is this a case of simple code is best?

Thanks, Iain

[steve rickus]

Iain, I use the node-red-contrib-moment node for all my date manipulations -- and yes it takes an integer timestamp as input. I think if you multiply your unix epoch * 1000 (to get millis as Nick mentioned), then pass it to the moment node, you can format the output date to anything you need.

[Julian Knight]

My node-red-contrib-moment node should do that for you, you can feed it any date and convert to any format.

[Glenn]

Can it add time? I want a date to be formatted and UTC+10

[Julian Knight]

I cannot (currently) do time calculations but it can certainly reformat to UTC+10

[Glenn]

Nice, so if the payload is 2017-05-28T21:00:00-04:00

Can it be converted to UTC +10 and formatted as Sunday 28th May 2017?

[Julian Knight]

Urm no, because your input date is actually on the 29th UTC

So 21:00 on 28th in timezone UTC-4 is 01:00 on the 29th in UTC and 11:00 on the 29th in UTC+10

My node SHOULD(!) do that perfectly well. Unfortunately, it seems to have a couple of bugs as you can see from the following flow :(

[{"id":"ce06a058.827b4","type":"moment","z":"106ba95c.ff91e7","name":"UTC-4","topic":"UTC-4","input":"payload","inputType":"msg","inTz":"UTC-4","adjAmount":0,"adjType":"days","adjDir":"add","format":"ddd Do MMM YYYY HH:mm","locale":"en_GB","output":"","outputType":"msg","outTz":"UTC-4","x":410,"y":2380,"wires":[["676487bc.944dc8"]]},{"id":"daf66c4.a26919","type":"inject","z":"106ba95c.ff91e7","name":"2017-05-28T21:00:00-04:00","topic":"","payload":"2017-05-28T21:00:00-04:00","payloadType":"str","repeat":"","crontab":"","once":false,"x":160,"y":2380,"wires":[["ce06a058.827b4","16d02d70.722663","df86678e.f6f1d8"]]},{"id":"676487bc.944dc8","type":"debug","z":"106ba95c.ff91e7","name":"","active":true,"console":"false","complete":"false","x":730,"y":2380,"wires":[]},{"id":"16d02d70.722663","type":"moment","z":"106ba95c.ff91e7","name":"UTC","topic":"UTC","input":"payload","inputType":"msg","inTz":"UTC-4","adjAmount":0,"adjType":"days","adjDir":"add","format":"ddd Do MMM YYYY HH:mm","locale":"en_GB","output":"","outputType":"msg","outTz":"UTC","x":410,"y":2420,"wires":[["676487bc.944dc8"]]},{"id":"df86678e.f6f1d8","type":"moment","z":"106ba95c.ff91e7","name":"UTC+10","topic":"UTC+10","input":"payload","inputType":"msg","inTz":"UTC-4","adjAmount":0,"adjType":"days","adjDir":"add","format":"ddd Do MMM YYYY HH:mm","locale":"en_GB","output":"","outputType":"msg","outTz":"UTC+10","x":420,"y":2460,"wires":[["676487bc.944dc8"]]},{"id":"f5741865.49d2c8","type":"inject","z":"106ba95c.ff91e7","name":"2017-05-28T21:00:00-04:00","topic":"","payload":"2017-05-28T21:00:00","payloadType":"str","repeat":"","crontab":"","once":false,"x":160,"y":2460,"wires":[["df86678e.f6f1d8","16d02d70.722663","ce06a058.827b4"]]}]

It appears to be ignoring both the input and output timezone!

However, you can specify the input timezone using the input msg as with the first input in the example. I think the output timezone is being taken from the locale or maybe UTC, not sure yet.

Thankfully, you can also add/subtract and offset manually and I'd forgotten that so you should simply add 14 hours to your input (or adjust to get what you need).

[Julian Knight]

Spotted the problem. Unbeknown to me, moment.timezone does not recognise fixed offsets like "UTC-4", you have to use a locality setting like "America/Los_Angeles" so my node was actually ignoring the timezone specified in the node settings.

In the github version, you now get a warning and the tz is explicitly set to UTC if you specify something wrong.

I still need to update docs and possibly add GMT/UTC +/- to the timezones manually.

On Tuesday, 23 May 2017 17:40:18 UTC+1, Julian Knight wrote:

Urm no, because your input date is actually on the 29th UTC

So 21:00 on 28th in timezone UTC-4 is 01:00 on the 29th in UTC and 11:00 on the 29th in UTC+10

My node SHOULD(!) do that perfectly well. Unfortunately, it seems to have a couple of bugs as you can see from the following flow :(

...

[Glenn]

Great. Glad my time blunder made you find this out.

The node seems easy enough to use

[Julian Knight]

Well, it was certainly meant to be easy :)

As a recap - you can work around the issue I discovered by feeding the input tz via the msg (e.g. include the tz in the input timestamp) and use the adjust feature to compensate for the output tz.

[steve rickus]

I have not tried it, but from the source data it appears that "GMT-4" is a valid timezone, while "UTC-4" is not.

[Julian Knight]

Hmm, I tried GMT-4 and it still baulked.

OK, got it - the actual correct entry is "etc/gmt-4" - I don't think case matters.

I can now add some manual exceptions so that people don't have to remember all that.

[Julian Knight]

[{"id":"ce06a058.827b4","type":"moment","z":"106ba95c.ff91e7","name":"UTC-4","topic":"UTC-4","input":"payload","inputType":"msg","inTz":"etc/GMT-4","adjAmount":0,"adjType":"days","adjDir":"add","format":"ddd Do MMM YYYY HH:mm","locale":"en_GB","output":"","outputType":"msg","outTz":"etc/GMT-4","x":410,"y":2380,"wires":[["676487bc.944dc8"]]},{"id":"daf66c4.a26919","type":"inject","z":"106ba95c.ff91e7","name":"2017-05-28T21:00:00-04:00","topic":"","payload":"2017-05-28T21:00:00-04:00","payloadType":"str","repeat":"","crontab":"","once":false,"x":160,"y":2380,"wires":[["ce06a058.827b4","16d02d70.722663","df86678e.f6f1d8"]]},{"id":"676487bc.944dc8","type":"debug","z":"106ba95c.ff91e7","name":"","active":true,"console":"false","complete":"false","x":730,"y":2380,"wires":[]},{"id":"16d02d70.722663","type":"moment","z":"106ba95c.ff91e7","name":"UTC","topic":"UTC","input":"payload","inputType":"msg","inTz":"etc/GMT-4","adjAmount":0,"adjType":"days","adjDir":"add","format":"ddd Do MMM YYYY HH:mm","locale":"en_GB","output":"","outputType":"msg","outTz":"etc/GMT","x":410,"y":2420,"wires":[["676487bc.944dc8"]]},{"id":"df86678e.f6f1d8","type":"moment","z":"106ba95c.ff91e7","name":"UTC+10","topic":"UTC+10","input":"payload","inputType":"msg","inTz":"etc/GMT-4","adjAmount":0,"adjType":"days","adjDir":"add","format":"ddd Do MMM YYYY HH:mm","locale":"en_GB","output":"","outputType":"msg","outTz":"etc/GMT+10","x":420,"y":2460,"wires":[["676487bc.944dc8"]]},{"id":"f5741865.49d2c8","type":"inject","z":"106ba95c.ff91e7","name":"2017-05-28T21:00:00-04:00","topic":"","payload":"2017-05-28T21:00:00","payloadType":"str","repeat":"","crontab":"","once":false,"x":160,"y":2460,"wires":[["df86678e.f6f1d8","16d02d70.722663","ce06a058.827b4"]]}]

[Julian Knight]

Published the new v2.0.5 version which autocorrects those common timezone errors (e.g. utc+4 actually needs to be etc/gmt+4). Should you manage to enter an invalid tz, it will output a warning and use UTC instead. Also, blank timezones are auto-set to the hosts locale settings now.

On Wednesday, 24 May 2017 16:35:45 UTC+1, Julian Knight wrote: