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?
Background
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, 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 the timeZone option to toLocaleString 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 Apring 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. )
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;
// 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 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 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);
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.
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.
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);
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 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;
}
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
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.
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!)
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
}
//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);
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!!
var reportDateStr = "2018-05-21";
var reportDate = new Date(reportDateStr);
var y = reportDate.getFullYear();
var lastDateOfReportYear = new Date(reportDate.getFullYear(), 11, 31);
console.log(lastDateOfReportYear)
Instead of getting the last day of the year 2018 which is Dec 31, 2018, I am getting Jan 31, 2019
Please, can you tell me what is wrong with the above code and why I am getting Jan 31, 2019?
To be honest, without digging deeper into what browser/node version you are using (we will get to why that matters in a moment), I am a bit uncertain as to why you are getting a date a month later (Jan 1, 2019 would make much more sense for the issue you are running into) but I will give a higher level explanation for why Jan 1, 2019 might be happening.
From the Date documentation:
Note: Where Date is called as a constructor with more than one argument, the specified arguments represent local time. If UTC is desired, use new Date(Date.UTC(...)) with the same arguments.
So because your are constructing a new date with three parameters, the date represents your local time.
const localDate = new Date(2018, 11, 31);
console.log({
localDate // in EST this will be "2018-12-31T05:00:00.000Z"
});
Notice the hours is "05" (for EST) and not "00". Using Date.UTC as recommended will make it "00" regardless of local time.
const localDate = new Date(Date.UTC(2018, 11, 31));
console.log({
localDate // This will always be "2018-12-31T00:00:00.000Z"
});
A few other things to note when creating a Date from a date string (which is not recommended):
Note: parsing of date strings with the Date constructor (and Date.parse, they are equivalent) is strongly discouraged due to browser differences and inconsistencies. Support for RFC 2822 format strings is by convention only. Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local.
So the date generated can be different due to various JavaScript implementations. Check out this chart for a reference on this issue.
Also note that getFullYearuses the local time to get the full year value. This can impact your desired output as well.
So, to be a bit more safe you could use UTC for all of your calculations:
const reportDateStr = '2018-05-21';
const reportDate = new Date(reportDateStr); // This could still be problematic
const y = reportDate.getUTCFullYear();
const lastDateOfReportYear = new Date(Date.UTC(y, 11, 31));
console.log(lastDateOfReportYear.toUTCString());
There are also libs like moment.js that can help with the multitude of issues dealing with times and dates.
You are doing too much work in something is always going to be the same.
December ALWAYS is going to be 31 days and the last month of the year is always going to be december, so why dont you just get the year and append to it 12-31
Example:
var reportDateStr="2018-05-21";
console.log(reportDateStr.substr(0,4)+'-12-31')
Now, If you want to keep your function make sure the TimeZone where you are. Your code works fine with the Eastern Time
See the working snippet below,
I added some consoling from your code and comments to make it simple:
var reportDateStr = "2018-05-21";
var reportDate = new Date(reportDateStr);
var y = reportDate.getFullYear();
var lastDateOfReportYear = new Date(y , 11, 31);
// For me the below returns the 30th December, 11pm
console.log('Date:', lastDateOfReportYear);
// … because I've got -120 as offset!
console.log('TimezoneOffset:', new Date().getTimezoneOffset());
// You need to use this one to get rid of the Timezones:
var lastDateOfReportYear_2 = new Date(Date.UTC(y , 11, 31));
console.log('Date UTC:', lastDateOfReportYear_2);
Hope it helps.
I am using the Javascript function toLocaleString() to convert date object into string (As it's output is very user friendly), for storage purpose, and then I want to fetch that saved data (obviously in the form of string) later, and I want to compare such to dates.
I have date stored in this format : February 5, 2016 7:04:40 PM IST
But That's not possible directly, so I tried to convert that string to date object using both implicit (using Date constructor) and explicit (Using Date Object) methods. But it gives Invalid date, as output, when printed.
Then I google a lot to find out how can I convert date from this format directly back to the Date Object so that I can perform the desired date operations. But I couldn't found anything worth using.
Please help me to came out with a solution to that problem, so that I can complete my project.
If you really need to use pure javascript you should create a function which parses your string in order to use those arguments to create a date object.
var months = {
'january': 0,
'february': 1,
'march': 2,
'april': 3,
'may': 4,
'june': 5,
'july': 6,
'august': 7,
'september': 8,
'october': 9,
'november': 10,
'december': 11,
};
var strDate = "February 5, 2016 7:04:40 PM IST";
var parts = strDate.split(' ');
var year = parts[2];
var month = months[parts[0].toLowerCase()];
var day = parts[1].replace(/\,/g,"");
var timeParts = parts[3].split(':');
var hours = timeParts[0];
var minutes = timeParts[1];
var seconds = timeParts[2];
if (parts[4]==="PM") {
hours = parseInt(hours) + 12;
}
var d = new Date(year, month, day, hours, minutes, seconds);
alert(d.toLocaleString());
In the futur please put a little more efforts into it. You could've easily written this yourself.
edit 2 : Actually none of this was needed. You can use the Date.parse() function as long if you remove the IST from the end.
var strDate = "February 5, 2016 7:04:40 PM";
var d = new Date("February 5, 2016 7:04:40 PM");
alert(d.toLocaleString());
Then if you want you can set the timezone manually.
I am using the Javascript function toLocaleString() to convert date object into string (As it's output is very user friendly), for storage purpose
That is not a good idea. You should store data in the best format for storage and present to users in the best format for humans. The two are often different.
and then I want to fetch that saved data (obviously in the form of string) later, and I want to compare such to dates.
Far better to store the date in a format that your database supports natively, or as an ISO 8601 compliant string. There is no standard for time zone abbreviations, but I'll guess that IST is India Standard Time, which is +0530. The equivalent UTC ISO 8601 string is "2016-02-05T13:34:40Z", which can be created from your initial Date object using toISOString.
Then, when you read from the database, convert to whatever format is required for use.
Most ECMAScript hosts will correctly parse "2016-02-06T13:34:40Z", however some will not. A simple parser that also validates the values is:
function parseISO(s) {
var b = s.split(/\D/);
var d = new Date(Date.UTC(b[0],--b[1],b[2],b[3],b[4],b[5],(b[6]?(b[6]+'000').slice(0,3):0)))
return d && d.getUTCMonth() == b[1] && d.getUTCHours() == b[3] &&
d.getUTCMinutes() == b[4]? d : new Date(NaN);
}
document.write(parseISO('2016-02-05T13:34:40Z').toLocaleString());