admin管理员组文章数量:1126351
I have date time in a particular timezone as a string and I want to convert this to the local time. But, I don't know how to set the timezone in the Date object.
For example, I have Feb 28 2013 7:00 PM ET,
then I can
var mydate = new Date();
mydate.setFullYear(2013);
mydate.setMonth(02);
mydate.setDate(28);
mydate.setHours(7);
mydate.setMinutes(00);
As far as I know, I can either set the UTC time or local time. But, how do I set time in another timezone?
I tried to use the add/subtract the offset from UTC but I don't know how to counter daylight savings. Am not sure if I am heading the right direction.
How can I go about converting time from a different timezone to local time in javascript?
I have date time in a particular timezone as a string and I want to convert this to the local time. But, I don't know how to set the timezone in the Date object.
For example, I have Feb 28 2013 7:00 PM ET,
then I can
var mydate = new Date();
mydate.setFullYear(2013);
mydate.setMonth(02);
mydate.setDate(28);
mydate.setHours(7);
mydate.setMinutes(00);
As far as I know, I can either set the UTC time or local time. But, how do I set time in another timezone?
I tried to use the add/subtract the offset from UTC but I don't know how to counter daylight savings. Am not sure if I am heading the right direction.
How can I go about converting time from a different timezone to local time in javascript?
Share Improve this question edited Dec 2, 2018 at 22:10 Matt Johnson-Pint 241k75 gold badges462 silver badges607 bronze badges asked Feb 28, 2013 at 17:22 pavanredpavanred 13.8k16 gold badges56 silver badges59 bronze badges 5 |24 Answers
Reset to default 939Background
JavaScript's Date
object tracks time in UTC internally, but typically accepts input and produces output in the local time of the computer it's running on. It has very few facilities for working with time in other time zones.
The internal representation of a Date
object is a single number - namely timestamp - representing the number of milliseconds that have elapsed since 1970-01-01 00:00:00 UTC
, without regard to leap seconds.
There is no time zone or string format stored in the Date object itself.
When various functions of the Date
object are used, the computer's local time zone is applied to the internal representation. If the function produces a string, then the computer's locale information may be taken into consideration to determine how to produce that string. The details vary per function, and some are implementation-specific.
The only operations the Date
object can do with non-local time zones are:
It can parse a string containing a numeric UTC offset from any time zone. It uses this to adjust the value being parsed, and stores the UTC equivalent. The original local time and offset are not retained in the resulting
Date
object. For example:var d = new Date("2020-04-13T00:00:00.000+08:00"); d.toISOString() //=> "2020-04-12T16:00:00.000Z" d.valueOf() //=> 1586707200000 (this is what is actually stored in the object)
In environments that have implemented the ECMASCript Internationalization API (aka "Intl"), a
Date
object can produce a locale-specific string adjusted to a given time zone identifier. This is accomplished via thetimeZone
option totoLocaleString
and its variations. Most implementations will support IANA time zone identifiers, such as'America/New_York'
. For example:var d = new Date("2020-04-13T00:00:00.000+08:00"); d.toLocaleString('en-US', { timeZone: 'America/New_York' }) //=> "4/12/2020, 12:00:00 PM" // (midnight in China on April 13th is noon in New York on April 12th)
Most modern environments support the full set of IANA time zone identifiers (see the compatibility table here). However, keep in mind that the only identifier required to be supported by Intl is
'UTC'
, thus you should check carefully if you need to support older browsers or atypical environments (for example, lightweight IoT devices).
Libraries
There are several libraries that can be used to work with time zones. Though they still cannot make the Date
object behave any differently, they typically implement the standard IANA timezone database and provide functions for using it in JavaScript. Modern libraries use the time zone data supplied by the Intl API, but older libraries typically have overhead, especially if you are running in a web browser, as the database can get a bit large. Some of these libraries also allow you to selectively reduce the data set, either by which time zones are supported and/or by the range of dates you can work with.
Here are the libraries to consider:
Intl-based Libraries
New development should choose from one of these implementations, which rely on the Intl API for their time zone data:
- Luxon (successor of Moment.js)
- date-fns-tz (extension for date-fns)
- Day.js (when using its Timezone plugin)
Non-Intl Libraries
These libraries are maintained, but carry the burden of packaging their own time zone data, which can be quite large.
- js-joda/timezone (extension for js-joda)
- moment-timezone* (extension for Moment.js)
- date-fns-timezone (extension for older 1.x of date-fns)
- BigEasy/TimeZone
- tz.js
* While Moment and Moment-Timezone were previously recommended, the Moment team now prefers users chose Luxon for new development.
Discontinued Libraries
These libraries have been officially discontinued and should no longer be used.
- WallTime-js
- TimeZoneJS
Future Proposals
The TC39 Temporal Proposal aims to provide a new set of standard objects for working with dates and times in the JavaScript language itself. This will include support for a time zone aware object.
Common Errors
There are several approaches that are often tried, which are in error and should usually be avoided.
Re-Parsing
new Date(new Date().toLocaleString('en', {timeZone: 'America/New_York'}))
The above approach correctly uses the Intl API to create a string in a specific time zone, but then it incorrectly passes that string back into the Date
constructor. In this case, parsing will be implementation-specific, and may fail entirely. If successful, it is likely that the resulting Date
object now represents the wrong instant in time, as the computer's local time zone would be applied during parsing.
Epoch Shifting
var d = new Date();
d.setTime(d.getTime() + someOffset * 60000);
The above approach attempts to manipulate the Date
object's time zone by shifting the Unix timestamp by some other time zone offset. However, since the Date
object only tracks time in UTC, it actually just makes the Date
object represent a different point in time.
The same approach is sometimes used directly on the constructor, and is also invalid.
Epoch Shifting is sometimes used internally in date libraries as a shortcut to avoid writing calendar arithmetic. When doing so, any access to non-UTC properties must be avoided. For example, once shifted, a call to getUTCHours
would be acceptable, but a call to getHours
would be invalid because it uses the local time zone.
It is called "epoch shifting", because when used correctly, the Unix Epoch (1970-01-01T00:00:00.000Z
) is now no longer correlated to a timestamp of 0
but has shifted to a different timestamp by the amount of the offset.
If you're not authoring a date library, you should not be epoch shifting.
For more details about epoch shifting, watch this video clip from Greg Miller at CppCon 2015. The video is about time_t
in C++, but the explanation and problems are identical. (For JavaScript folks, every time you hear Greg mention time_t
, just think "Date
object".)
Trying to make a "UTC Date"
var d = new Date();
var utcDate = new Date(Date.UTC(d.getUTCFullYear(), d.getUTCMonth(), d.getUTCDate(), d.getUTCHours(), d.getUTCMinutes(), d.getUTCSeconds(), d.getUTCMilliseconds()));
In this example, both d
and utcDate
are identical. The work to construct utcDate
was redundant, because d
is already in terms of UTC. Examining the output of toISOString
, getTime
, or valueOf
functions will show identical values for both variables.
A similar approach seen is:
var d = new Date();
var utcDate = new Date(d.getUTCFullYear(), d.getUTCMonth(), d.getUTCDate(), d.getUTCHours(), d.getUTCMinutes(), d.getUTCSeconds(), d.getUTCMilliseconds());
This is approach passes UTC values into the Date
constructor where local time values are expected. The resulting Date
object now represents a completely different point in time. It is essentially the same result as epoch shifting described earlier, and thus should be avoided.
The correct way to get a UTC-based Date
object is simply new Date()
. If you need a string representation that is in UTC, then use new Date().toISOString()
.
As Matt Johnson said
If you can limit your usage to modern web browsers, you can now do the following without any special libraries:
new Date().toLocaleString("en-US", {timeZone: "America/New_York"})
This isn't a comprehensive solution, but it works for many scenarios that require only output conversion (from UTC or local time to a specific time zone, but not the other direction).
So although the browser can not read IANA timezones when creating a date, or has any methods to change the timezones on an existing Date object, there seems to be a hack around it:
function changeTimezone(date, ianatz) {
// suppose the date is 12:00 UTC
var invdate = new Date(date.toLocaleString('en-US', {
timeZone: ianatz
}));
// then invdate will be 07:00 in Toronto
// and the diff is 5 hours
var diff = date.getTime() - invdate.getTime();
// so 12:00 in Toronto is 17:00 UTC
return new Date(date.getTime() - diff); // needs to substract
}
// E.g.
var here = new Date();
var there = changeTimezone(here, "America/Toronto");
console.log(`Here: ${here.toString()}\nToronto: ${there.toString()}`);
This should solve your problem, please feel free to offer fixes. This method will account also for daylight saving time for the given date.
dateWithTimeZone = (timeZone, year, month, day, hour, minute, second) => {
let date = new Date(Date.UTC(year, month, day, hour, minute, second));
let utcDate = new Date(date.toLocaleString('en-US', { timeZone: "UTC" }));
let tzDate = new Date(date.toLocaleString('en-US', { timeZone: timeZone }));
let offset = utcDate.getTime() - tzDate.getTime();
date.setTime( date.getTime() + offset );
return date;
};
How to use with timezone and local time:
dateWithTimeZone("America/Los_Angeles",2019,8,8,0,0,0)
You can specify a time zone offset on new Date()
, for example:
new Date('Feb 28 2013 19:00:00 EST')
or
new Date('Feb 28 2013 19:00:00 GMT-0500')
Since Date
store UTC time ( i.e. getTime
returns in UTC ), javascript will them convert the time into UTC, and when you call things like toString
javascript will convert the UTC time into browser's local timezone and return the string in local timezone, i.e. If I'm using UTC+8
:
> new Date('Feb 28 2013 19:00:00 GMT-0500').toString()
< "Fri Mar 01 2013 08:00:00 GMT+0800 (CST)"
Also you can use normal getHours/Minute/Second
method:
> new Date('Feb 28 2013 19:00:00 GMT-0500').getHours()
< 8
( This 8
means after the time is converted into my local time - UTC+8
, the hours number is 8
. )
It's now 2023, this question is 10 years old, with 1.1m views, but I was unhappy with all of the above solutions.
The original question was:
[if] I have
"Feb 28 2013 7:00 PM ET"
, then [...] as far as I know, I can either set the UTC time or local time. But, how do I set time in another timezone?
- Matt Johnson-Pint's answer was excellent, and almost was enough, but it stopped short of directly answering the question. The answer demonstrates setting a date in another time zone, but does so using the UTC offset (
+08:00
) rather than by timezone name as per the original question.- This points us to the "right" solution: specifying the UTC offset when we create the date; we just need to convert from the IANA time zone to UTC offset
- commonpike's answer and chicken's answer both re-parse the locale-specific format, which is not standard Javascript and Mozilla advises against
- They both also create a Date object that doesn't actually represent the desired UTC date and time
- maowtm's answer was also almost right, but again it doesn't use the only format supported in the Javascript specification.
- The other answers all suffer from the errors/bugs that Matt Johnson-Pint pointed out, and/or re-parsing non-standard formats.
The "right" way in 2023
Modern browsers and node.js>=18 give a list of ~400 time zones with the following query:
const tzs = Intl.supportedValuesOf("timeZone"); // [ "Africa/Abidjan", "Africa/Accra" ...]
console.log(tzs);
For each listed timezone we can get a GMT/UTC offset by constructing a DateTimeFormat instance, formatting a new date with the longOffset
formatter, and parsing the result:
// gives '2/28/2013, GMT-05:00'
const tzname = "America/Detroit";
const longOffsetFormatter = new Intl.DateTimeFormat("en-US", {timeZone: tzname ,timeZoneName: "longOffset"});
const longOffsetString = longOffsetFormatter.format(new Date("2013-02-28T19:00:00.000")); // '2/28/2013, GMT-05:00'
// longOffsetString.split('GMT')[1] will give us '-05:00'
const gmtOffset = longOffsetString.split('GMT')[1];
console.log(longOffsetString);
console.log(gmtOffset);
Now we can construct a new Date, properly (i.e. internally it will have the correct UTC date/time), using the timezone offset string.
// Feb 28 2013 7:00 PM EST
const gmtOffset = '-05:00'; // see above to figure out where this came from
const d = new Date("2013-02-28T19:00:00.000" + gmtOffset);
console.log(d.toISOString()); // '2013-03-01T00:00:00.000Z' (UTC)
console.log(d.toLocaleString("en-US", {timeZone: "America/Detroit"})); // '2/28/2013, 7:00:00 PM'
I found the most supported way to do this, without worrying about a third party library, was by using getTimezoneOffset
to calculate the appropriate timestamp, or update the time then use the normal methods to get the necessary date and time.
var mydate = new Date();
mydate.setFullYear(2013);
mydate.setMonth(02);
mydate.setDate(28);
mydate.setHours(7);
mydate.setMinutes(00);
// ET timezone offset in hours.
var timezone = -5;
// Approximate check for daylight savings if applicable (northern hemisphere)
var startDate = new Date(mydate.getFullYear(), 02, 31);
var endDate = new Date(mydate.getFullYear(), 09, 31);
var is_daylight_savings = mydate.getTime() >= startDate.getTime() && mydate.getTime() <= endDate.getTime();
if (is_daylight_savings) {
timezone += 1;
}
// Timezone offset in minutes + the desired offset in minutes, converted to ms.
// This offset should be the same for ALL date calculations, so you should only need to calculate it once.
var offset = (mydate.getTimezoneOffset() + (timezone * 60)) * 60 * 1000;
// Use the timestamp and offset as necessary to calculate min/sec etc, i.e. for countdowns.
var timestamp = mydate.getTime() + offset,
seconds = Math.floor(timestamp / 1000) % 60,
minutes = Math.floor(timestamp / 1000 / 60) % 60,
hours = Math.floor(timestamp / 1000 / 60 / 60);
// Or update the timestamp to reflect the timezone offset.
mydate.setTime(mydate.getTime() + offset);
// Then Output dates and times using the normal methods.
var date = mydate.getDate(),
hour = mydate.getHours();
EDIT
I was previously using UTC
methods when performing the date transformations, which was incorrect. With adding the offset to the time, using the local get
functions will return the desired results.
For Ionic users, I had hell with this because .toISOString()
has to be used with the html template.
This will grab the current date, but of course can be added to previous answers for a selected date.
I got it fixed using this:
date = new Date();
public currentDate: any = new Date(this.date.getTime() - this.date.getTimezoneOffset()*60000).toISOString();
The *60000 is indicating the UTC -6 which is CST so whatever TimeZone is needed, the number and difference can be changed.
I ran into this issue running a GCP Cloud Function. Of course it works on a local machine, but running in the cloud makes the OS default (local) for new Date()
irrelevant. In my case, an api call from the cloud required Eastern Standard Time, in ISO format (without the "Z") with offset as "-0500" or "-0400" depending on DST, for example:
2021-12-01T00:00:00.000-0500
Again, this is not a browser formatting issue, so I am forced into this format for the api call to work correctly.
Using @chickens code as a start, this is what worked:
var date = new Date();
var now_utc = Date.UTC(date.getUTCFullYear(), date.getUTCMonth(), date.getUTCDate(),
date.getUTCHours(), date.getUTCMinutes(), date.getUTCSeconds());
var dt = new Date(now_utc);
let utcDate = new Date(dt.toLocaleString('en-US', { timeZone: "UTC" }));
let tzDate = new Date(dt.toLocaleString('en-US', { timeZone: "America/New_York" }));
let offset1 = utcDate.getTime() - tzDate.getTime();
let offset2 = offset1/60000;
let o1 = Math.abs(offset2);
console.log(offset2)
var offsetValue1 = (offset2 < 0 ? "+" : "-") + ("00" + Math.floor(o1 / 60)).slice(-2) + ("00" + (o1 % 60)).slice(-2);
console.log(offsetValue1)
dt.setTime(dt.getTime() - offset1);
console.log(dt.toISOString());
console.log(dt.toISOString().slice(0,-1)+offsetValue1);
I ran into a similar problem with unit tests (specifically in jest when the unit tests run locally to create the snapshots and then the CI server runs in (potentially) a different timezone causing the snapshot comparison to fail). I mocked our Date
and some of the supporting methods like so:
describe('...', () => {
let originalDate;
beforeEach(() => {
originalDate = Date;
Date = jest.fn(
(d) => {
let newD;
if (d) {
newD = (new originalDate(d));
} else {
newD = (new originalDate('2017-05-29T10:00:00z'));
}
newD.toLocaleString = () => {
return (new originalDate(newD.valueOf())).toLocaleString("en-US", {timeZone: "America/New_York"});
};
newD.toLocaleDateString = () => {
return (new originalDate(newD.valueOf())).toLocaleDateString("en-US", {timeZone: "America/New_York"});
};
newD.toLocaleTimeString = () => {
return (new originalDate(newD.valueOf())).toLocaleTimeString("en-US", {timeZone: "America/New_York"});
};
return newD;
}
);
Date.now = () => { return (Date()); };
});
afterEach(() => {
Date = originalDate;
});
});
I had the same problem but we can use the time zone we want
we use .toLocaleDateString()
eg:
var day=new Date();
const options= {day:'numeric', month:'long', year:"numeric", timeZone:"Asia/Kolkata"};
const today=day.toLocaleDateString("en-IN", options);
console.log(today);
I'm not sure why all these answers are so complicated. Just use YYYY-MM-DD ZZZ
when creating a date-only date in the local / desired time zone.
Create a local date:
var myDate = new Date('2022-11-29 CST')
The date will be stored in storage as UTC, great.
Get the date out of storage and display it as local:
myDate.toLocaleDateString()
11/29/2022
Building on the answers above, I am using this native one liner to convert the long timezone string to the three letter string:
var longTz = 'America/Los_Angeles';
var shortTz = new Date().
toLocaleString("en", {timeZoneName: "short", timeZone: longTz}).
split(' ').
pop();
This will give PDT or PST depending on the date provided. In my particular use case, developing on Salesforce (Aura/Lightning), we are able to get the user timezone in the long format from the backend.
Try: date-from-timezone, it resolves expected date with help of natively available Intl.DateTimeFormat
.
I used that method in one of my projects for few years already, but it's now I decided to publish it as small OS project :)
Try using ctoc from npm. https://www.npmjs.com/package/ctoc_timezone
It has got simple functionality to change timezones (most timezones around 400) and all custom formats u want it to display.
Thanks to @commonpike answer, I wrote a function which takes an ISO String date such as 2020-10-10T08:00:00.000
as input and send an object which contains 2 main properties.
The first one is fromUtc
is a Date corresponding to the timeZone entered as parameter.
The second one is toUtc
which lets you to format a Date stemming from fromUtc
.
const timeZoneTransformer = (stringDate, timeZone = "Europe/Paris") => {
const now = new Date();
const serverDate = new Date(stringDate);
const utcDate = new Date(
Date.UTC(
serverDate.getFullYear(),
serverDate.getMonth(),
serverDate.getDate(),
serverDate.getHours(),
serverDate.getMinutes(),
serverDate.getSeconds()
)
);
const invdate = new Date(
serverDate.toLocaleString("en-US", {
timeZone,
})
);
const diff = now.getTime() - invdate.getTime();
const adjustedDate = new Date(now.getTime() - diff);
return {
toUtc: utcDate,
fromUtc: adjustedDate,
};
};
const fromUtc = timeZoneTransformer("2020-10-10T08:00:00.000").fromUtc;
console.log(fromUtc);
const toUtc = timeZoneTransformer(fromUtc).toUtc;
console.log(toUtc);
Just like how @cobberboy felt in 2023, Same thoughts here and i tried one more approach, Using Intl.DateTimeFormat for setting up the timezone.
new Intl.DateTimeFormat('en-GB', {
timeZone: 'America/Los_Angeles',
}).format(new Date())
This will convert the current local timezone date to the given timezone.
Using Other Attritbutes like dateStyle: 'full'
and timeStyle: 'long'
you can get the date and time. Along with that there are other attributes as well such as timeZoneName where instead of passing America/Los_Angeles
you can pass other formats like PST
As the function returns string passing it to new Date
instance will be easy and can to further processing on it if needed.
I know its 3 years too late, but maybe it can help someone else because I haven't found anything like that except for the moment-timezone library, which is not exactly the same as what he's asking for here.
I've done something similar for german timezone, this is a little complex because of daylight saving time and leap years where you have 366 days.
it might need a little work with the "isDaylightSavingTimeInGermany" function while different timezones change on different times the daylight saving time.
anyway, check out this page: https://github.com/zerkotin/german-timezone-converter/wiki
the main methods are: convertLocalDateToGermanTimezone convertGermanDateToLocalTimezone
I've put an effort into documenting it, so it won't be so confusing.
Try something like this,
public static getTimezoneOffset(timeZone: string, date = new Date()): number {
const localDate = date.toLocaleString('fr', { timeZone, timeZoneName: 'long' });
const tz = localDate.split(' ');
const TZ = localDate.replace(tz[0], '').replace(tz[1], '').replace(' ', '');
const dateString = date.toString();
const offset = (Date.parse(`${dateString} UTC`) - Date.parse(`${dateString}${TZ}`)) / (3600 * 1000);
return offset;
}
There are several working answers here, but somehow a lot of them seemed to get you to the string, but not back to a date object you started with, so here's my simple non-function take on how to change timezone on JS date:
var TZ='Australia/Brisbane'; //Target timezone from server
var date = new Date(); //Init this to a time if you don't want current time
date=new Date(Date.parse(date.toLocaleString("en-US", {timeZone: TZ})));
//Just a clarification on what happens
// 1) First new Date() gives you a Date object at current time in the clients browser local timezone
// 2) .toLocaleString takes that time, and returns a string if time in the target timezone
// 3) Date.parse converts that new string to a Unix epoch number
// 4) new Date() converts the Unix epoch into a Date object in the new TimeZone.
// Now I can use my usual getHours and other Date functions as required.
Hope that helps others (if you get to this bottom answer!)
I had the same problem as OP which brought me to this thread and many others. None of the answers were able to "initialize a JavaScript Date to a particular time zone".
My scenario was a user selecting a date and a timezone (for a meeting), so whether in Unix time stamp, or UTC, etc, needed that dateTime to be in a given timezone, without knowing the offset from the users local time. Example user is in ? locale needs to set a meeting for 10:30 CST without knowing offset from local time. It's surprisingly difficult to set a certain date time from a different date time.
The following solution will instantiate a dateTime object in a non local timezone or converts a dateTime object to a different timezone, while maintaining the time it was originally set at. It is compliant with all modern browsers (and pretty decently far back), does not do anything questionable with browser apis, and takes in IANA date strings.
const setDateInAnotherTimeZone=(inputDateTime, timeZone)=>{
/**
* This funciton will instantiate a dateTime object in a non local timezone
* or
* Converts a dateTime object to a different timezone, while maintining the time
* Parameters
** inputDateTime, a date object with the desired time and day selected (in the local/non-desired timezone)
*** Example: new Date(2023, 10, 10, 10, 30) 10:30 (localalized to user timezone) on 10/30/2023
** timeZone, the desired timezone you want to set the date in.
*** Example: var timeZone = 'US/Central'
*** Requires a 'tz database time zone' name aka an IANA timezone name
*** Usefull list here https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
*** Date.prototype.toLocaleString() usng IANA time zone names is widely supported
*** https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleString#browser_compatibility
*/
console.log('desired Time Zone',timeZone)
console.log('desired Time ', inputDateTime.toString().split(" ").slice(4,5).join(' ').toString())
console.log('inputDateTime', inputDateTime)
const dateTZShifted = inputDateTime.toLocaleString("en-US", {timeZone : timeZone , dateStyle: 'long', timeStyle: 'long'})
let timeTZShifted = dateTZShifted.split(" ").slice(4,5).join(' ').toString().split(':')
var originalTime = inputDateTime.toString().split(" ").slice(4,5).join(' ').toString().split(':')
let newLocalTime = [
Number(originalTime[0]) - Number(timeTZShifted[0]) + Number(originalTime[0]) ,
Number(originalTime[1]) - Number(timeTZShifted[1]) + Number(originalTime[1]) ,
Number(originalTime[2]) -Number(timeTZShifted[2]) + Number(originalTime[2])
]
let outputDate = new Date(inputDateTime)
outputDate.setHours(Number(newLocalTime[0]), Number(newLocalTime[1]),Number(newLocalTime[2]))
console.log('outputDateTime ', outputDate.toLocaleString("en-US", {timeZone : timeZone , dateStyle: 'long', timeStyle: 'long'}) )
return(outputDate)
}
//Usage
let dateInAnotherTimeZone = setDateInAnotherTimeZone(new Date(2023, 7, 10, 10, 30),'US/Central')
let dateInAnotherTimeZone1 = setDateInAnotherTimeZone(DateObject,'America/New_York')
Expected Output
desired Time Zone US/Central
desired Time 10:30:00
inputDateTime
Thu Aug 10 2023 10:30:00 GMT-0400 (Eastern Daylight Time)
outputDateTime
August 10, 2023 at 10:30:00 AM CDT
or
Thu Aug 10 2023 11:30:00 GMT-0400 (Eastern Daylight Time)
If you are having problem with toISOString()
try like this using 'UTC'
in new Date()
method:
let start = new Date();
let event = new Date(`${start} UTC`);
event.setUTCHours(0, 0, 0, 0);
console.log(event.toISOString()); //2023-10-30T00:00:00.000Z
Simple with Node.JS support
Pass in the amount of hours your timezone is offset from UTC
function initDateInTimezone(offsetHours) {
const timezoneOffsetInMS = offsetHours * 60 * 60000;
let d = new Date().getTimezoneOffset() * 60000 + timezoneOffsetInMS;
const date = new Date(new Date().getTime() - d);
return date
}
Was facing the same issue, used this one
Console.log(Date.parse("Jun 13, 2018 10:50:39 GMT+1"));
It will return milliseconds to which u can check have +100 timzone intialize British time Hope it helps!!
//For Mumbai time difference is 5.5 hrs so
city_time_diff=5.5; //change according to your city
let time_now = Date.now();
time_now = time_now + (3600000 * city_time_diff); //Add our city time (in msec);
let new_date = new Date(time_now);
console.log("My city time is: ", new_date);
本文标签: timezoneHow to initialize a JavaScript Date to a particular time zoneStack Overflow
版权声明:本文标题:timezone - How to initialize a JavaScript Date to a particular time zone - Stack Overflow 内容由网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:http://www.betaflare.com/web/1736672791a1947013.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
d = new Date()
thend.getHours()
in the console, change your computer's time zone by an hour, and tryd.getHours()
again. There is no local time zone information stored ind
. – lynn Commented Dec 8, 2020 at 2:15