Develop Reference

The date 2019-04-01T00:00:00.000Z gives me previous month (March, not April)

So, I have the 1st day of month as 2019-04-01T00:00:00.000Z
When I use moment(date).month(), it returns me 2, not 3.
So, I receive March, not April.
What is the problem with it, and why I receive the previous month from the date? Maybe the problem in the TimeZone? Because my TimeZone is GMT-4, so, maybe this is problem?
Should I use UTC or ISO string instead to work with the date?

Like you mentioned, your timezone is GMT-4. The date that you are providing is in UTC. The 'Z' at the end stands for Zulu time, which is the same as UTC.
momentjs will convert this to local time.
How to handle this all depends on what you need the date for.
If this is a date that you saved somewhere before on a server, it might be important to add the correct timezone to it when you are saving it.
Be careful if you let a server create these dates, because the server might be running in a different timezone than your client.
If you create a new Date() in JS it will return a date object with the current time of your local time. If this happens on a server that's running in a different timezone, or in UTC (for example Docker containers), it will create a date in that timezone.
The best way to solve this is to think about your exact use case.
There are tons of articles written about handling dates and it's not easy.
If you have some time, this podcast helps to explain how dates work and will help you to get a better understanding of dates in general:
Coding Blocks - Why Date-ing Is Hard

new Date() in wrong time zone

At the time of this post my current time is 2017-01-10T19:23:00.000Z
but new Date() gives me 2017-01-11T00:23:19.521Z 5 hours ahead of my current timezone. This affects the way my data is stored in my MongoDB. I know I can set the time to 5 hours ago using
var datetime = new Date();
datetime.setHours(datetime.getHours()-5);
But I will prefer a better way to do this. I tried using this. I still got the same time. In other parts of my code I get Tue Jan 10 2017 19:54:30 GMT-0500 (EST) different from the initial time. I will be happy if someone can point out what's wrong here.

Using moment.js is the easiest way to accomplish what you are asking.
moment().format() // "2017-01-11T13:56:15-05:00"
The output is a string in ISO-8601 format, with time zone offset in effect in your local time zone.
You could do this yourself with a lot of code that reads the various properties of the Date object, building a string from those values. But it is not built-in to the Date object in this way.
Also, note any time you try to adjust a Date object by a time zone offset, you are simply picking a different point in time. You're not actually changing the behavior of the time zone being used by the Date object.

If you don't want to use any exteral JS file, You can simply use following code to get current timezone.
new Date().toString();

javascript new Date() or moment.js parse date wrong

I have a DateTime value that comes from server in the following format:
2015-08-16T01:29:00.000Z
However when I do
new Date('2015-08-16T01:29:00.000Z')
the result is this:
Sun Aug 16 2015 04:29:00 GMT+0300 (FLE Daylight Time)
please notice the hour is wrong, instead of 01:29 AM is 04:29 AM
Same for moment.js it get's the wrong hour.
How can I solve this?

It's the same time -- the server gives it to you as UTC (hence the Z at the end) and Javascript then helpfully shows it in the local timezone of the browser, FLE Daylight Time. Given that both times clearly state which timezone they are, nothing is going wrong, strictly speaking.
What to do depends on what you want exactly. By doing
moment.utc('2015-08-16T01:29:00.000Z');
You put moment.js in UTC mode, showing everything in UTC (if I understand the docs correctly).

Is there a simple time to get a timezone from a given time?

I need to get a timezone from a time, date is not important, but daylight savings is.
something like:
timezone = function("15:00");
Is there a simple way to do this?

I dont think you can get the timezone from the time but you might get some help from Date.prototype.getTimezoneOffset()
The getTimezoneOffset() method returns the time-zone offset from UTC,
in minutes, for the current locale.
Example:
var x = new Date();
var currentTimeZoneOffsetInHours = x.getTimezoneOffset() / 60;

No, of course not. Think about it, you're passing 15:00 to that function, presumable denoting it's 3PM. But in what timezone is it 3 PM? No way of knowing. It's like me saying it's quarter to, without saying what hour it's quarter to to.
The only way you can get a timezone in JS is by using the Date object, but that just shows the timezone of the machine on which your code is running, nothing about the TZ that "created" the time you're processing.
Also note that daylight saving isn't a global phenomenon, quite the contrary. AFAIKT, there isn't a single time-zone where DST has always been in place...

In order to get TimeZone information you need more than a Date (and an offset). You need a location.
Javascript does not know the location that it resides in but it does know the current offset from UTC. That is different than a Time Zone. The daylight savings time issue play havoc with this key difference.
This has posed problems when dealing with server applications that know their timezone and report dates as being in a specific Time Zone.
My rule of thumb has been fairly simple in this regard.
Always use Long or long (a 64 bit number) to store, pass and process dates times or intervals, only convert to Date, Calendar or DateTime objects when interacting with people.

Once you have a date object, such as with new Date(), you can use .getTimezoneOffset() to get the number of minutes between the date's object and UTC, which is timezone information you can use.

Representing a date in JavaScript when timezone is irrelevant

I am working on a very small JavaScript library that allows users to retrieve content based on date. For this content, the date is just an identifier and timezones are completely irrelevant (think along the lines of a Dilbert flip calendar). The "May 14th" content is the same whether you are in the United States or Australia.
The function for retrieving data currently takes a Date object as a parameter. Within the function, the timezone is ignored. Does this approach make sense, or would it be better to take a timezone-independent identifier (like 2012-01-01) as a parameter instead? With the Date object approach, do I run the risk of returning the wrong data as a result of timezone adjustments browsers make?

How about using Date.getUTC*() functions? UTC time is the same for everyone.

After doing some research, it appears that simply ignoring the timezone information is the best approach. Why? This will always preserve the date and time that were provided to the Date constructor (which is my goal), whereas the getUTC* methods will return altered versions of the date and time. For example, take a look at this node REPL session I ran on a computer in the Eastern Time zone.
> d = new Date(2013, 03, 27, 23, 00, 00)
Sat Apr 27 2013 23:00:00 GMT-0400 (EDT)
> d.getDate() // The same date provided in the constructor. Woo!
27
> d.getUTCDate() // A different date. Boo!
28
Long story short, if you want to read the exact date and time that were provided in the Date constructor, using the normal get* methods (like getDate) will do that. If you use the getUTC* methods (like getUTCDate) modified versions of the date and time will be returned.
I know this may sound rudimentary to some of the more experienced programmers out there, but this really helped me make sense of things. I hope it helps others who come along.

The only problem with the approach in your own answer is that it doesn't account for ambiguous times. This happens during daylight savings fall-back transitions.
For example, set your computer's time zone to US Mountain Time ("Mountain Time (US & Canada)" on windows, or "America/Denver" on mac/linux). Then restart your browser and run the following javascript:
var dt = new Date(2013,10,3,1,0);
alert(dt);
This is November 3rd, 2013 at 1:00 AM. But you don't know which 1:00 AM it is representing. Is it in Mountain Daylight Time (UTC-6) before the transition, or Mountain Standard Time (UTC-7) after? There's no way to tell, and JavaScript will just use the standard time.
Now if all you need is 2013-11-03 01:00 - then you are correct. You can just ignore the offset and be done with it. But if you are going to use that value for anything meaningful - such as recording a point in time, or subtracting from another point in time for duration between them, then you have a problem that you can't resolve without the offset.
Unfortunately, there is no great solution for this problem in JavaScript. The closest thing is Moment.js, but it is still not perfect yet. Still, it is better than the Date object by itself, because it gets around browser inconsistencies and provides better parsing and formatting.