0

I can get local date and time from a timestamp by IANA time zone name through this way:

let dateString = timestamp.toLocaleString('en-GB', { timeZone: "America/New_York" });

But what about time zone offset? I get the offset in client side by getTimezoneOffset which returns offset in minutes like -120 or +260.

Client sends their offset to server. Server (Node) must turn the timestamps (Stored in DB) to their local date time and send it back.

My clients use old version of JS. So Intl is not available.

Robert junior
  • 140
  • 1
  • 8
  • Your question mixes client- and server-side JavaScript. What, specifically, is your question? You can't know the client's time zone offset from the server unless you send it in a request. Many systems send the date/time in UTC, along with the client's offset from UTC, and store both. – Heretic Monkey Oct 11 '22 at 21:57
  • No I had visited that question before. – Robert junior Oct 11 '22 at 21:57
  • @HereticMonkey yeah client sends their offset to server side with a request. Server side must convert stored timestamps to their local time based on offset and send it back. – Robert junior Oct 11 '22 at 21:58
  • 1
    So, again, what is the actual question? – Heretic Monkey Oct 11 '22 at 21:59
  • @HereticMonkey how to convert a timestamp to local date by timezone offset? `toLocaleString` does it by IANA name. I need to do it by offset. – Robert junior Oct 11 '22 at 22:01
  • Does the client send the timezone offset for a specific date or date range? If it's only sending the current offset then that could cause problems. – Yogi Oct 11 '22 at 22:33
  • @Yogi they send only one integer which represent their location offset from UTC. – Robert junior Oct 11 '22 at 22:36
  • Yeah, but that's not always the same. My offset now is +1:00 CET, but that would be incorrect for a July timestamp using +2:00 CEST. So the timestamp would be off. I don't see how you can solve this problem using a simple integer offset as that lacks the information needed to calculate the correct time for a location. – Yogi Oct 11 '22 at 22:53
  • @Yogi Do you know what `toLocaleString('en-GB', { timeZone: "America/New_York" })` actually does? – Robert junior Oct 11 '22 at 22:56
  • From the question, all the server knows is the offset sent from the client. The server can only guess at the timezone name from that offset. +1 could be Norway or South Africa. And if the server guesses wrong then the timestamp calculation it sends back could be wrong as SA doesn't use DST. Too bad the question was closed as it wasn't really a duplicate of that other question (as you said). – Yogi Oct 11 '22 at 23:52
  • @Yogi Yes...Thanks. This is SO dictatorship :)) – Robert junior Oct 12 '22 at 01:18
  • [Edit] your post to talk about what your actual question is, and how it differs from the one posted. This is what [the help center advises as well](/help/duplicates). @Yogi you have the necessary rep to vote to reopen the question as well. – Heretic Monkey Oct 12 '22 at 14:31
  • in dealing with date and time, you should always store unix timestamp on the server side, it provides a point in time and can be converted into any localized time. Pass ts back to the client and use client locality to convert back to local time. IF you need to know *local time-of-day* for events, you should send the ISO 8601 datestring, which will have local time with offset (FOR THE EVENT TIME), and can be parsed on the server side into its components. I insist on 'offset for the event time' because offsets change when you have daylight saving changes. – MrE Oct 13 '22 at 05:25
  • @MrE Thanks. Yes I could solve the issue with a similar approach. – Robert junior Oct 14 '22 at 23:56

0 Answers0