Date Picker -Dashboard question

Dashboard
1

I am using the date picker on a web form. I then proceed to store it into a database.
The problem I have it sends the date in msg.payload as "1571826972734" I would like this to be human readable. Looking at the github documentation doesn't show anyway to configure that except to change the format of it. as in mm-dd-yyyy or yyyy-mm-dd etc but it still sends the 1571826972734 as a value.

I can see if I use a debug node and click on the output it is able to translate it into a date.
2 questions come from this.

  1. can I change the date that it sends via msg.payload?
  2. If I cant do 1 then what is the formula it is using that I can convert it back from 1571826972734 to human readable via a function node?
2

You can use a function node to change it back to human time.

var d = new Date(msg.payload);
var str = d.toDateString; //Wed Oct 23 2019
msg.payload = str;

Check out Javascript Date Functions for more formats.

Hope this helps

3

ohh man. I was so close. I thought originally it was unix time but converting it gave horribly wrong times!
Thanks this does help :slight_smile: Appreciate it
After much dinking around with your suggestion I have got it to work with this
var d = new Date(msg.payload);
var day = d.getDate();
var month = d.getMonth();
var monthformat = month + 1;
var year = d.getFullYear();
msg.payload = day +"-"+ monthformat +"-"+ year;

1 Like
4

in general you should do the conversion when reading back out of a database rather than before going in - so when the clock changes for summer/winter time you won't get duplicate entries or a gap.

5

That is a good idea. right now they are being stored as the date picker submits them. I am using an html template node to put them into a table. I would like to format the ones with the dates to that :slight_smile:

6

I agree with Dave -- please do not store any timestamps in human-readable strings! You will end up with a database that cannot be searched by date/time ranges, and will be near impossible to present correctly to users in different timezones...

The only exception is to use the ISO-8601 date formatting -- which is simple to do in JS:

var d = new Date(msg.payload);
msg.payload = d.toISOString();
return msg;

When you pull apart the internal Date object into its "day" value, for instance, you can get the *local" day of the month, not the actual GMT date (depending upon your timezone offset and how close to midnight it is). Same thing with transitions between months, years, and daylight savings time!

Bottom Line: Always store the internal date in its native format, and format it for output display only... your life will be simpler, and your applications more predictable and easy to maintain.

1 Like
7

Oh, and if you really don't need the time component at all, it's best to use the format yyyy-MM-dd -- not only does it sort chronologically, but JS can interpret it back into a Date object easily:

// convert a GMT date string into a Date in my local timezone
> new Date("2019-05-04").toDateString()
'Fri May 03 2019'    <--- since I am behind the International Date line

// convert a local date string into a local Date object in my tz
> new Date("2019-05-04".split("-")).toDateString()
'Sat May 04 2019'

Using the m/d/yyyy format is ambiguous -- 4/5/2019 would be "April 5, 2019" in the U.S. but it could be interpretted as "May 4, 2019" in Europe...

1 Like