Wsrtjtyk

Date stored in server at GMT+0 without Day Light Saving.

Client should receive it in it's own timezone format. So we can get time zone offset and summarize it with received date:

const currentTime = new Date();

this.timezoneOffset = currentTime.getTimezoneOffset();

Then we can check if client in DLS region somehow, for example using momentjs:

 const isDaylightSavingTime = moment().isDST();

And there I can't figure out 3 things:
1) does getTimezoneOffset() already contain Day Light Saving information
2) and if not, what the better way to check is user in DST then moment (because I readed thet moment js have not some countries and cities in it's own base)
3) does Moment().add(Moment().utcOffset(), 'm') return date with Day Light Saving?

And there I can't figure out 3 things:
1) does getTimezoneOffset() already contain Day Light Saving information

Moment is a wrapper for ECMAScript Date objects. The timezone offset for a built–in Date instance is based on host system settings. Depending on the implementation, it may or may not reflect historic changes to timezones for the related date (i.e. the Date that the method is called on). It will at least reflect the current settings.

2) and if not, what the better way to check is user in DST then moment (because I readed thet moment js have not some countries and cities in it's own base)

You need to define "better". In addition to other libraries (e.g. Luxon), there are web APIs like timezonedb and Date.prototype.toLocaleString with the timeZone option that uses IANA location names like "Asia/Shanghai". You can also download and use the IANA timezone database if you wish.

3) does Moment().add(Moment().utcOffset(), 'm') return date with Day Light Saving?

You can't modify the timezone offset, there is only a getter, so any "local" date will have the timezone offset applied, whether that be the standard or daylight saving offset for the particular date and location. All the above does is shift the time by the offset, it doesn't change the timezone (unless it's shifted across a daylight saving boundary).

Date objects are UTC at heart, so the general approach is to use UTC for everything and only consider the timezone offset for presentation. That doesn't cover all scenarios, but it does the majority. The remaining cases require specific approaches based on use cases.

If you describe what you are trying to do, you might get more relevant answers.