0
 new Date(Date.now()).toLocaleString(
            "en-US",
            {
              timeZone: "Asia/Calcutta"
            }
 )

Works for my timezone. But when I try to get for another timezone, it doesn't help. I tried using Date.parse() and moment, no luck. Would be helpful if there is some other way. I am trying to work on time setting feature for different timezones. Hence I need a function to return current time in that timezone.

Dark Frost
  • 43
  • 2
  • Hi. It's a bit unclear what you're asking, as the title of your question is talking about milliseconds, while `toLocaleString` returns a formatted string. It's also unclear why your question is tagged with `reactjs`, and what precisely you mean when you say "it doesn't help", or "no luck". Please read [*How do I ask a good question?*](https://stackoverflow.com/help/how-to-ask), and [*How to create a Minimal, Reproducible Example*](https://stackoverflow.com/help/minimal-reproducible-example) from the help center. Thank you. – Matt Johnson-Pint Dec 07 '19 at 21:28
  • The use of `Date.now()` in the OP is entirely redundant, the result of `new Date(Date.now())` is identical to `new Date()`. – RobG Dec 08 '19 at 00:38

2 Answers2

1

Time returned by Date.now() will be the same for any time zone, because it returns how many ms have passed since 01-01-1970

What you need is to calculate GMT offset for your desired time zone

var offset = new Date().getTimezoneOffset(); console.log(offset);

The time-zone offset is the difference, in minutes, between UTC and local time. Note that this means that the offset is positive if the local timezone is behind UTC and negative if it is ahead. For example, if your time zone is UTC+10 (Australian Eastern Standard Time), -600 will be returned. Daylight savings time prevents this value from being a constant even for a given locale

Calzonix
  • 36
  • 3
  • …except in places that don't observe daylight saving. ;-) But historical changes still apply (particularly pre 1900). – RobG Dec 08 '19 at 00:39
  • *getTimezoneOffset* returns the offset for the host system, it doesn't help the OP get a time value for a timestamp in a particular timezone. – RobG Dec 08 '19 at 11:43
1

ECMAScript Dates are simply a time value that is an offset from 1970-01-01T00:00:00Z (the ECMAScript epoch, which is the same as the Java and UNIX epoch).

If a system's clock is accurately set to the current time, then Date.now() and new Date().getTime() for a particular instant will return exactly the same value regardless of the timezone offset of the host system. In practice there will however be minor variations due to clock inaccuracies and lack of syncrhonisation.

The host timezone offset comes from the host system and is only used for calculations involving local values, it's not an attribute of the Date itself.

If you want to get the time value for a particular date and time for a particular timezone offset, you can build a string that should be parsable by the built–in parser and use that. E.g. the Line Islands have an offset of +14:00 and don't observe daylight saving, so to get the time value for Christmas morning use a supported string format1 and the built–in parser:

// Christmas morning in Line Islands
let s = '2019-12-25T00:00:00+14:00';
// Get time value
let ms = Date.parse(s);
let d = new Date(ms);

let optsLocal = {weekday:'short', day:'numeric', month:'short', year:'numeric', hour:'numeric', hour12:false, minute:'numeric'};
let optsHK = Object.assign({},optsLocal,{timeZone:'Asia/Hong_Kong'});
let optsNY = Object.assign({},optsLocal,{timeZone:'America/New_York'});
let optsHW = Object.assign({},optsLocal,{timeZone:'Pacific/Honolulu'});


console.log('Start string: ' + s +
            '\nTime value  : ' + ms + 
            '\nLocal date  : ' + d.toLocaleString('en-GB', optsLocal) +
            '\nHong Kong   : ' + d.toLocaleString('en-GB', optsHK) +
            '\nNew York USA: ' + d.toLocaleString('en-GB', optsNY) +
            '\nHawaii USA  : ' + d.toLocaleString('en-GB', optsHW)
);
  1. Where "supported string format" is one of the two formats specified in ECMA-262, also see Why does Date.parse give incorrect results?
RobG
  • 142,382
  • 31
  • 172
  • 209