Now I'm suffering for half an hour.
There is a server and client (browser)
On the server, the time zone is +3, in my browser I have +2, I send a message from the server to the client, it has a date in utc received on the server like this: new Date().getTime() + (new Date().getTimezoneOffset() * 60 * 1000)
In the browser, when I receive a message, I extract the date and make an alert(new Date(msg.date)) but the time in this date is already an hour less.
Why?

  • Apparently either in the browser, or on the server the daylight saving time is not configured, or upset ... - cyadvert
  • oops, like new Date().getTime() equivalent to Date.now() and both return time in UTC. you don’t need to touch the time zone yourself either - NumminorihSF

2 answers 2

To get time in UTC, you do not need to (new Date()).getTime() add the offset of the time zone. Because it will already be in UTC. Accordingly, a timestamp formed via new Date().getTime() or via Date.now() when used in the date constructor on the client will return the correct time except when the client or the server has the wrong time zone. To get a time stamper, use the 2nd method better; there is no point in initializing the whole object.

  • At first, I simply did getTime for everything that is written in utc but returns after being transferred to unixtime and transferred to the client, and there is a translation back in milliseconds and displaying so alert(new Date(date)) it did not show in utc, I thought that the reason was getTime which is not really in utc gives time, but it turned out that the reason is new Date() which leads to the current time zone, although this is not where it is not written. Data.how () - has no method - Vitaly Karpenko

Use unixtime ( Date.now () / 1000 ) on the server both when sending and working. This time does not depend on locales, time zones, etc. It is uniform both, for example, for USA, and for the Russian Federation. And already after, before the conclusion for the client, output it in the form of human-like and readable time in the right format (although, in my opinion, the need for this is not so common). What the client has installed (and you and the server) and how he set up his watch can only guess. But the main thing is that you will carry out all your calculations in the same time. And already what time zone on the server or you personally will not play any role.

  • Translated to unix timestamp, vserovno time an hour less - Vіtalіy Karpenko
  • @ Vitali, right. On the local machine, it will be reduced to the time set on the same machine, taking into account the time zone. But in itself it is unchanged. Those. You have some 32-bit number (for example, 1457553721). For me it is 23 hours (I have such a time zone). And for you, for example, it is 20 hours. So how many hours does it show you? I think you should easily understand the very essence of unixtime and local time of each individual computer / user. - Max ZS
  • If you follow your logic, then alert (new Date (some time in unix timestamp * 1000)) should not just display the time, but output it taking into account my time zone (+2), but it outputs from me to -1, and indeed Date () does not take into account the time of the date when passing a date through an argument - Vitaliy Karpenko
  • @ Vitaly Let's be easier. And what time do you see the link given by me? - Max ZS
  • Nothing shows, knocks on timeout by reference. - Vitaly Karpenko