Develop Reference

msg object is not readable info

Good day people of Stackoverflow...
I have a serious problem with the info I`m reading of my weather API.
I get info into a function node that exports the sunset and sunrise times,
now the problem is that it gives me the info in a weird way.
EG. Object:
sunrise: 1572060152
sunset: 1572106754
now if I click on the number it changes to a HEX. And if I click on it again it changes to something else, not sure what u call it but it looks like this "2019-10-26T03:22:32.000Z"
And then if I click it again I get the info that I require 10/26/2019, 5:32:32 AM [UTC+2]
I need to get the time extracted from that info but it doesn't matter what I try the outcome is always the 10 digit number...
Please help.

The OpenWeather node is returning timestamps in what is known ans epoc format. Epoc time is the number of seconds since 1st January 1970. This is basically how all computers work with time.
The Node-RED sidebar is just being helpful, in that when it sees a number that is in the right range, it will automatically convert it to different things when you click on it, in this case it is converting first to a hex representation (0x5DB47202) and then to a human readable timestamp (using what ever timezone your browser is using).
What you do with that value entirely depends on what you are going to do with it next, but assuming you want to display it to a user somewhere (e.g. in the Dashboard UI) then have a look at the node-red-contrib-moment node as this has lots of options for working with timestamps and converting them into other formats.

Compare date and time in javascript using time in milliseconds since epoch

Is it a good practice to compare the date and time using the epoch(UTC) time?
I checked it on internet, but did not got example of this. Does this approach has any negative?
if(date_utc1>dateutc2){
//do something
}
Here date_utc1 and date_utc2 are time in epoch

I gathered from the comments that one of the dates is a server-side generated date, but the other is a client-side generated date. Without fully understanding the logic involved here, I´d just like make a short note (sorry don´t have reps for comments) that these two clocks may not fully agree on time (represented in epoch or not).
If possible, a better solution is to only rely on one (the server´s) clock. When the client initially receives data from server, the client persist the server-side timestamp (needs to be part of the response). Down the line, if the client wants to check if the server has more data, the persisted value should be sent back. This way we are sure that the server only returns stuff that has been changed since the last fetch.

You can use Date.now() to get the current time in all recent browsers. You could also use +new Date() to obtain the same number in older browsers if you need to.
Since the data returned from the server is already a number in this milliseconds-since-epoch format, it makes sense to use this information for comparisons, since there is no other calculations or parsing of the data coming from the server that must be done.
I don't believe there are any negatives here.

Save time of day as number in mongodb, but display in a human format (using meteor autoform)

In a form, I'm asking for a start time & end time, which I'll be using in a script later on.
I figured in MongoDB, a time of day is best stored as the # of seconds since midnight (per How can I store time-of-day in MongoDB? As a string? Give arbitrary year/month/day?).
My question is: how can I display a human-readable time in autoform (e.g. 7:30pm) yet still save it as a number in mongodb & have proper client-side validation (make sure time is before 8:00pm)? I figure I could either use a datetime object & subtract the seconds since 1970, or I could parse the time string & do math on the hours, minutes, AM/PM.
Thoughts on methods? & where to put the math hooks in autoform? This seems like something folks a lot smarter than me have probably already figured out!

new Date(<unixTimeStamp>) will get you a javascript Date object which can be easily played with using libraries like moment (https://github.com/moment/moment)
Edit: also, to get the proper timestamp you can do +Date.now(). This jives with mongodb's date type

Asp-net web api output datetime with the letter T

the data in the DB look like this
2011-09-07 14:43:22.520
But my Web API outputs the data and replace the space with the letter T
2011-09-07T14:43:22.520
I can replace the letter T with a space again in jquery, but can I fix this problem from the Web API (make the web api output the original data?)
I also do not want the miliseconds at the end. How can I get rid of them?

The format of how you see the date in the database is usually irrelevant, because it should be passed into .Net as a DateTime - not as a string. (If you are storing it as a varchar in the database, you have a bigger problem.)
ASP.Net WebAPI is returning the value in format defined by ISO8601 and RFC3339. This is a good thing, as it is a recognized machine-readable format. You probably don't want to change it.
If you really want to change it, you would need to implement a custom JSON.Net JsonConverter, deriving from DateTimeConverterBase. This is discussed here and here.
But instead, you should consider how you are using the actual result in your client application. You mentioned jQuery, so I will assume your consumer is JavaScript. In many browsers, the ISO8601 value that you have is already recognized by the JavaScript Date constructor, so you might be able to just do this:
var dt = new Date("2011-09-07T14:43:22.520");
But this won't work in all browsers. And Date doesn't have a whole lot of flexibility when it comes to formatting. So instead, you might want to consider a library such as moment.js. With that in place, you can do this:
var m = moment("2011-09-07T14:43:22.520");
var s = m.format("YYYY-MM-DD HH:mm:ss"); // output: "2011-09-07 14:43:22"
Please note that the format string here conforms to moment.js, not to .NET. There are differences in case sensitivity. Please refer to the moment.js documentation for details.
One other thing - since the value you provided doesn't have either a Z at the end, nor does it have an offset such as -07:00, then I assume it came from a DateTime whos .Kind value is DateTimeKind.Unspecified. You should be aware that when this gets sent into JavaScript (or anywhere else for that matter), there is no information about what time zone is represented. JavaScript will assume the local time zone of the browser.
If that's not what you had intended, then you need to store UTC values in your database, and make sure they have DateTimeKind.Utc so they get serialized with a Z at the end. JavaScript will normalize this to the browser's time zone, but you will still be talking about the same moment in time.
Alternatively, you could use a DateTimeOffset type - which would serialize with the specific offset. JavaScript will still normalize this to the user's time zone.

Time Zone Sensitive Date and Time Display in Web Applications?

I am looking for recommendations on displaying times in a web application in a time zone other than the user's current time zone.
We store our dates/times in UTC/GMT in the database, so it is not an issue to format the time for UTC/GMT or the user's current time zone. However, in other situations we need to display the time from the point of view of an arbitrary time zone (i.e. every date/time on this page is in Eastern, regardless of whether or not the user is in West Coast, Central, Eastern, etc.).
In the past we have stored offsets or time zone info, then done the calculations in server code in .Net or else we have done some client-side manipulations in javascript that I would prefer to avoid, since it all becomes very dependent on javascript and the user's browser. I'd like to know the best way to do this in a more client-side/MVC type application.
Here is an example:
Date stored in db: 1302790667 (Thu, 14 Apr 2011 14:17:47 GMT)
Converted date displayed for a client in Central time zone: Thu Apr 14 09:17:47 2011
Date I actually want to display, always in Eastern time zone: Thu Apr 14 10:17:47 2011
In the above example, it's easy to get the time in UTC (#1) or the user's current time zone (#2) but it is more difficult to get #3. My options seem to be:
Store offsets or time zones in the db and do calculations on the client - this is what we've done in the past with .Net but it seems even messier in client side code is the path we are currently trying to avoid.
Do the conversion on the server and send down a full date for display to the client - client receives a string ("Thu Apr 14 10:17:47 2011"). This works but it's not very flexible.
Do the conversion on the server, break it into parts and send those down to the client, then put them back together. ("{DayOfWeek:Thu, Month:Apr, Day:14, Hour:10, Minute:17}"). This gives us the correct data and gives us more flexibility in formatting the date but it feels a little wrong for this scenario.
Any other options ideas? How do others handle similar situations? Thanks.

Our results:
I tried out a few libraries like Datejs, MS Ajax, etc. and I was never very happy with them. Datejs didn't work at all in a few of my test cases, is not actively maintained, and seemed to focus a lot on syntactic sugar that we don't need (date.today().first().thursday(), etc.)
We do use jQuery for some basic date/time parsing.
I came across a lot of "roll-your-own" client-side date conversion "hacks", most of which only addressed the conversion to UTC, started off working fine, and then eventually fell apart on some edge case. This one was the 90% solution for a lot of standard UTC conversion but didn't solve our "arbitrary timezone" issue.
Between the code complexity the conversion routines added and the bugs they seemed to cause, we decided to avoid client side date processing most of the time. We do the date conversions on the server with our existing date handling routines and pass the formatted dates or info down as properties to be used by the view. If we need a separate date, we just add another property. There are usually only a few properties that we need at a time (i.e. EventDateUTC, EventDateLocal, EventDateAlwaysAustralia, and EventDayOfWeek).

I offer the suggestion that you look into the Datejs library. It offers a bunch of extensions to basic JavaScript date manipulation, including a "setTimezone()" method and flexible ways to convert a date into a formatted string for display.
I usually hesitate to suggest libraries when their use is not explicitly allowed for in questions, but Datejs isn't very large and it's pretty solid (even though it's called an "alpha" release). If you'd prefer not to rely on something like that, you might want to look at it anyway just to see the basics of how its extensions were implemented.