I have the UTC date string "2022-01-06T13:35:00Z" and the time zone string "Romance Standard Time". How can use that time zone string in JavaScript (in a browser) so that I can get the time corrected to 14:35?
The time zone libraries that I have found so far uses the IANA time zone, e.g. "Europe/Copenhagen", so a library that can convert "Romance Standard Time" to something like "Europe/Paris" would also answer my question. It's acceptable that this conversion is done in .NET and not JavaScript.
The key was to understand that "Romance Standard Time" is a Windows time zone ID. Everyone else uses IANA time zone IDs. They have the region/city format, e.g. "Europe/Copenhagen".
In .NET 6 it's possible to convert between the formats. Here's the code example from Date, Time, and Time Zone Enhancements in .NET 6.
// Conversion from Windows to IANA when a region is unknown.
string windowsTimeZoneId = "Eastern Standard Time";
if (!TimeZoneInfo.TryConvertWindowsIdToIanaId(
windowsTimeZoneId, out string ianaTimeZoneId))
{
throw new TimeZoneNotFoundException(
$"No IANA time zone found for "{windowsTimeZoneId}".");
}
Console.WriteLine($"{windowsTimeZoneId} => {ianaTimeZoneId}");
// "Eastern Standard Time => America/New_York"
// Conversion from Windows to IANA when a region is known.
string windowsTimeZoneId = "Eastern Standard Time";
string region = "CA"; // Canada
if (!TimeZoneInfo.TryConvertWindowsIdToIanaId(
windowsTimeZoneId, region, out string ianaTimeZoneId))
{
throw new TimeZoneNotFoundException(
$"No IANA time zone found for "{windowsTimeZoneId}" in "{region}".");
}
Console.WriteLine($"{windowsTimeZoneId} + {region} => {ianaTimeZoneId}");
// "Eastern Standard Time + CA => America/Toronto"
If you're on an earlier version of .NET you can use TimeZoneConverter. Here's a complete list of the time zones in case you need to build your own converter: windowsZones.json.
This answer to this questions suggests using NodaTime, so that is probably also a possibility: Convert Windows timezone to moment.js timezone?
JavaScript
If you want to do it with Javascript, there is multiple Libraries. I am most familiar with moment.js, however they are deprecated, which means you might want to use another library if you are working on a new project.
List of suggested libraries by moment.js.
Anyways, if you wish to work with moment and convert to timezones, you could easily do that using Moment-Timezone. All supported timezones.
For example:
const moment = require('moment-timezone');
const timeZone = "Europe/Paris";
const ISOString = "2022-01-06T13:35:00Z"; //2022-01-06T13:35:00Z
const momentDefault = moment(ISOString).format(); //2022-01-06T14:35:00+01:00
const momentTz = moment.utc(ISOString).tz(timeZone).format(); //2022-01-06T14:35:00+01:00
As you see, moment gets the timezone by default and handels the ISOString as a UTC value, so it automatically converts the value to the timezone of the client user.
You still can specifically tell moment to handle the ISOString as a UTC ISOString and then convert it to a specific Timezone you defined. In that way the client's timezone will be ignored.
EDIT:
Now I realized that the questioner wants to convert the timezone from Windows to Iana before converting it in Javascript, because most libraries including Moment.js don't support windows timezone ids.
I found a nice library here.
And here is an example how to convert the timezone first and then use moment.js.
import { findIana } from 'windows-iana';
const moment = require('moment-timezone');
const result = findIana('Romance Standard Time');
console.log(result); // ['Europe/Paris', 'Europe/Brussels', 'Europe/Copenhagen', 'Europe/Madrid', 'Africa/Ceuta']
const timeZone = result[0]; //doesn't really matter which one to take, if you are just converting the times.
const ISOString = "2022-01-06T13:35:00Z"; //2022-01-06T13:35:00Z
const momentDefault = moment(ISOString).format(); //2022-01-06T14:35:00+01:00
const momentTz = moment.utc(ISOString).tz(timeZone).format(); //2022-01-06T14:35:00+01:00
.NET C#
To convert a time to a specific timezone in C#, you dont need any extra packages, you can simply do that as following:
var isoString = "2022-01-06T13:35:00Z";
var utcDate= DateTime.Parse(isoString);
var timeZone = "Romance Standard Time";
var date = TimeZoneInfo.ConvertTime(utcDate, TimeZoneInfo.FindSystemTimeZoneById(timeZone)); //01/06/2022 14:35:00
Here you can find list of all supported timezoneIds
Related
My time zone is GMT+8. and my AWS region is Singapore (ap-southeast-1)
My concern is they have different results when calculating dates, when i deployed my code in aws/lambda, i got different result from my local machine. what I want to achieve or my goal is that the AWS Lambda will have a same result like in my local
my local result: 2023-04-05T16:00:00.000Z
lambda result: 2023-04-06T00:00:00.000Z
code:
const moment = require('moment');
const dateToday = new Date();
const today = dateToday.toLocaleDateString();
const accumulatedDate = moment.utc(new Date(today)).add(118, 'days').toISOString();
console.log(accumulatedDate);
The toLocaleDateString() method returns a string with a language-sensitive representation of the date portion of the specified date in the user agent's timezone.
I think the issue is that you are converting your local timestamp to be represented as UTC, rather than just using UTC.
The toUTCString() method converts a date to a string, interpreting it in the UTC time zone.
You're seeing this result because toLocaleDateString() truncates the time. But "truncate the time" is inherently a timezone-sensitive operation. If you convert a date+time to a date, you need to decide which time zone's midnight you're going to use to truncate the time.
For example, assume a time like 2000-01-01T04:00Z. In New York (UTC-5), toLocaleDateString('en-US') would return '12/31/1999' (which, when converted to UTC, is 1999-12-31T05:00Z). While in London it'd return '2000-01-01' (which, when converted to UTC, is 2000-01-01T00:00Z).
If you want to get the same result on your local machine as on the server, then you'll need to use the same time zone in both places. Which time zone you use depends on the use cases of your app. For example, if you want to report on "Sales made yesterday at our store in Shanghai" then you'll probably want to use the Asia/Shanghai time zone. If you are writing to a log file, then you'll probably want to use UTC. If you're summarizing revenue for a multinational corporation headquartered in Marseille, then you'll probably want to use Europe/Paris. And so on.
BTW, instead of moment.js. you may want to look at Temporal, which is a new JavaScript built-in object that will be shipping in browsers and Node.js soon, likely within the next year or so. Temporal is the successor API to JavaScript's venerable Date object, and it has first-class support for time zones and date/time arithmetic. There are Temporal polyfills available now. (Full disclosure: for the last few years I helped to lead the team that designed the Temporal API.)
Using Temporal, your code could look something like this:
import { Temporal } from '#js-temporal/polyfill';
// If you want to use UTC
const today = Temporal.Now.plainDateISO('UTC'); // 2022-12-14
const accumulatedDate = today.add({ days: 118 }).toString(); // 2023-04-11
// If you want to use a specific time zone
const today = Temporal.Now.plainDateISO('Asia/Singapore'); // 2022-12-15
const accumulatedDate = today.add({ days: 118 }).toString(); // 2023-04-12
I've got a form where I input an event that starts at a certain time. Let's say 9am.
To assign a date/time object I'm using MomentJs. The issue comes when displaying it in different time-zones.
In London will show up 9am as intended - in Kiev will show 11am.
How can I make MomentJS and the browser ignore which timezone is relevant for the user, and just displaying the time I'm giving?
Here's my code:
<p>
Start time:
{moment(event.startDate).format("HH:mm")}
</p>
Assuming you have stored the date as utc (which in this case you probably should have), you could use the following:
moment.utc(event.startDate).format("HH:mm")
Let me provide an alternative answer in Vanilla JavaScript. If you want to make it timezone 'neutral', you can first convert it to UTC using toISOString().
const current = new Date();
const utcCurrent = current.toISOString();
console.log(utcCurrent);
If you want to convert it to a specific timezone, such as London, you can use toLocaleString(). Do take note of the browser support for the timezone though.
const londonTime = new Date().toLocaleString('en-US', { timeZone: 'Europe/London' })
console.log(londonTime);
What you want is a normalized Datetime. This can get a little confusing since the concept of timezones is a rather arbitrary construct.
I like to think of Datetime values as "absolute" and "relative". An "absolute" Datetime is one that is true regardless of which timezone you're in. The most common example of these are UTC(+000) and UNIX Time (also known as Unix epoch, POSIX Time or Unix Timestampe).
UTC is pretty obvious. Its the current time at +000 timezone. UNIX time is a bit more interesting. It represents the number of seconds that have elapsed since January 1, 1970.
You should always store data, in both client and backend, as an "absolute" time. My preference is UNIX time since its represented as a single integer (nice and clean).
moment.js does this for you. When you instantiate your moment object, you can use:
var date = moment.utc(utcString)
or for Unix Time
var date = moment.unix(unixInt)
You can then use this object to display the date in any form you wish:
console.log(date.tz.("America/Toronto"))
The only way I could solve this is by removing the timezone and milliseconds info from the string. I used date-fns lib but I imagine moment will work the same way.
import { format } from 'date-fns'
const myDateTimeString = '2022-02-22T19:55:00.000+01:00'
const dateTimeWithoutTimezone = myDateTimeString.slice(0, 16) // <- 2022-02-22T19:55
format(new Date(dateTimeWithoutTimezone), 'HH:mm')
I have a requirement, where I need to show a user's time in their local time zone. This needs to be done using date-fns.
The following code checks the current time and then given a timezone converts it into local time as per the time zone.
const { formatToTimeZone } = require('date-fns-timezone')
let date = new Date()
const format = 'D.M.YYYY HH:mm:ss [GMT]Z (z)'
const output = formatToTimeZone(date, format, { timeZone: 'Asia/Calcutta' })
However, how do I guess the user's timezone on the fly?
In moment.js, you can get it with moment.tz.guess(). But how can I do it without moment.js and by using date-fns?
https://runkit.com/embed/835tsn9a87so
UPDATE: I will be using this inside a VueJS application. So, if there are any other related solutions, those are welcomed as well. Thanks.
To get the user's IANA time zone identifier, most modern browsers now support the following:
Intl.DateTimeFormat().resolvedOptions().timeZone
That said, the usual reason you would need to use formatToTimeZone from date-fns-timezone is when you need to use a different time zone other than the user's local zone. Otherwise, you can usually just use the format function from date-fns.
However, in your case, you are also trying to use the z format specifier to display the user's time zone abbreviation. This isn't provided by date-fns directly, so if that is critical then you will indeed need to get the user's time zone with the Intl api shown above and use formatToTimeZone.
Do keep in mind though that these abbreviations are whatever the IANA data has recorded, which are in English only, and it doesn't have abbreviations for every time zone. For those that don't, you will see a numeric value instead, such as -02.
Also, many abbreviations can be ambiguous (such as the I in IST possibly meaning India, Israel, or Ireland, and many others...). Thus, in most cases, if you don't need the abbreviation, you're often better off without it.
Just solved a similar problem myself. The trick is to use the format function from date-fns-tz instead of the one from date-fns.
import { format } from "date-fns";
console.log(format(new Date(), "yyyy-MM-dd HH:mm z"));
// 2021-11-29 13:55 GMT-8
import { format } from "date-fns-tz";
console.log(format(new Date(), "yyyy-MM-dd HH:mm z"));
// 2021-11-29 13:55 PST
See documentation here:
https://date-fns.org/v2.27.0/docs/Time-Zones
I need to make illusion of working in the selected by the user timezone. The problem that server and client code are stick to javascript date. So to achieve the requirement I have made mannualy mapping from utc to the date on the client side:
dateToServer(date) {
const momentDate = moment(date);
let serverDate = null;
if (momentDate.isValid() && date) {
const browserUtcOffset = momentDate.utcOffset();
serverDate = momentDate
.utc()
.subtract(this.clientTimeZoneOffset, 'minutes')
.add(browserUtcOffset, 'minutes')
.toDate();
}
return serverDate;
}
dateToClient(date) {
const momentDate = moment(date);
let uiDate = null;
if (momentDate.isValid() && date) {
const browserUtcOffset = momentDate.utcOffset();
uiDate = momentDate
.utc()
.subtract(browserUtcOffset, 'minutes')
.add(this.clientTimeZoneOffset, 'minutes')
.toDate();
}
return uiDate;
}
I'm adding/subtracting the browserUtcOffset, because it is adding/subtracting automatically by browser when the date is go between server and client.
It was working well, but this solution is missing handling of the DST. I'd like to check is DST active for the date and then add DST offset if need.
Here C# code, that can do this:
string timeZone = "Central Standard Time";
TimeZoneInfo timeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById(timeZone);
DateTime date = new DateTime(2011, 3, 14);
Console.WriteLine(timeZoneInfo.BaseUtcOffset.TotalMinutes); // -360
Console.WriteLine(timeZoneInfo.GetUtcOffset(date).TotalMinutes); // -300
Console.WriteLine(timeZoneInfo.IsDaylightSavingTime(date)); // true
Console.WriteLine(timeZoneInfo.DaylightName);
Console.WriteLine(timeZoneInfo.SupportsDaylightSavingTime);
I have found the isDST in the momentjs, and when I have my windows local timezone to CST and check moment([2011, 2, 14]).isDST(); in browser console I see the true. How you can see the isDST is depends on the browser local time.
Next step try to use moment-timezone to do smth like I have done in C#. Unfortunately I don't understand how to achieve this. The first problem that as start point I have: UTC time, Base offset(-360 in C# sample), timezone name: Central Standard Time, but timezones in the moment-timezone are different.
moment.tz.names().map(name => moment.tz.zone(name)).filter(zone => zone.abbrs.find(abbr => abbr === 'CST') != null) this code returns 68 timezones.
Why there each of them have many abbrs? What mean untils? All I want to check if UTC time in the selected timezone, which is "Central Standard Time", the daylight saving day active. See C# sample one more time :)
string timeZone = "Central Standard Time";
TimeZoneInfo timeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById(timeZone);
DateTime date = new DateTime(2011, 3, 14);
Console.WriteLine(timeZoneInfo.BaseUtcOffset.TotalMinutes); //-360
Console.WriteLine(timeZoneInfo.GetUtcOffset(date).TotalMinutes); //-300
Console.WriteLine(timeZoneInfo.IsDaylightSavingTime(date)); //true, I have checked is daylightsavingtime for the date
Console.WriteLine(timeZoneInfo.DaylightName);
Console.WriteLine(timeZoneInfo.SupportsDaylightSavingTime);
The application has been written on the angularjs 1.6.3.
A few things:
The Date object in JavaScript tracks a specific UTC-based point in time. You can see that timestamp with a call to .valueOf() or .getTime(). It is only certain functions and constructor parameters that work with the local time zone (such as .toString()). That local time zone is applied at the time the function is called. One cannot substitute a different time zone (except in the options object passed to toLocaleString). Thus, the Date object can not be converted from one time zone to another. Because your two functions both take in a Date object and return a Date object, all you are doing in the middle is picking a different point in time. This is also seen inside the function where you use the add and subtract methods of Moment. They manipulate the represented point in time - they do not change the time zone.
By passing this.clientTimeZoneOffset, You appear to have conflated a time zone with a time zone offset. These are separate concepts, as a time zone may go through multiple different offsets, due to DST but also due to changes in standard time, where they have occurred in history. See also "Time Zone != Offset" in the timezone tag wiki. It is not useful to pass just the client's offset, as that offset only applies to a single point in time. You cannot use it for time zone conversions, because it doesn't tell you anything about which offsets are used for other points in time.
Instead, pass a time zone identifier. On Windows in .NET, these look like "Central Standard Time" (representing both standard and daylight time despite the name), and in JavaScript and most other operating systems, IANA time zone names are used. They look like "America/Chicago". This is also covered in the timezone tag wiki.
If your .NET code is using Windows identifiers, you can use my TimeZoneConverter library to convert from Windows to IANA, then send that string to the browser as the time zone.
With Moment-Timezone, you can simply check the DST like so:
moment.tz([2011, 2, 14], 'America/Chicago').isDST()
Again, you should be using IANA time zone IDs, and TimeZoneConverter can provide them if you're using Windows time zones server-side.
You could consider using Noda Time on the server-side, with its TZDB time zone provider. That would allow you to use IANA time zones on both sides. This is also the case with TimeZoneInfo when run on .NET Core on Linux or Mac OSX.
The reason you see so many entries when you searched for abbreviations with CST is that time zone abbreviations are ambiguous. You may have meant US Central Standard Time, but you might also have meant Cuba Standard Time or China Standard Time, or a variety of other places that use that abbreviation.
Regarding the untils array, you generally don't need to concern yourself with that. It is part of the internal data that Moment-Timezone uses to pick the correct point in time for choosing a time zone offset and abbreviation.
You said at the end, something slightly different:
All I want to check if UTC time in the selected timezone, which is "Central Standard Time", the daylight saving day active.
The example I gave earlier assumed you were starting with that time zone's local time. If you're starting with the UTC time, then it's like this:
moment.utc([2011, 2, 14]).tz('America/Chicago').isDST()
Of course, you can pass various other supported inputs where I pass the array. The Moment docs can help you with available options.
Check please the answer of Matt Johnson for this question. It was very usefull for me.
Vocabulary
UI date - the date that user see on the html date input when
selecting the date. UI date is the native js date.
Server date - the UTC date that is stored in the
database.
timezone id - string, that identified the timezone. They are different for windows(.net), IANA(javascript) and rails conventions.
Problem
The main problem f.e. when a man logged in on the PC which is located in the timezone +3, but setting for his account is -6. The angularjs and kendo is using on the project and the kendo time is working only with native js date. And native js date is always in the browser timezone, for this example +3. But I should setup the stuff like it in -6. F.e. example user has selected time 07:00, the UTC will be 04:00 (07:00 - 3), but as for his account the timezone is -6, the utc should be 13:00 (07:00 + 6). And this conversations are applied automatically when we converting native js date(UI date) to UTC and backward. So decision to count the offset on the server and get rid off browser timezone offset: utcTime = UItime + browserOffset - clientTimezoneBaseOffset - daylightSavingTimeOffset.
However there is problem when need to get UI time back, f.e. today 06.06.2014 and the DST is true for this date, but when we are getting 03.03.2014 date from server we don't know if the DST was active for 03.03.2014.
Answer
In project on the server the .net, so in database the window's timezone IDs are stored. I have done it the next way: count on server DST for date ranges in the range from minimum date on the server and save on the client in the local storage. I like that in this case
the server is one source of truth, so the calculations can be performed on any client without manipulating the timezones. And no need to convert between IANA, Windows and rails timezones. But also there is a problem: need to precalculate DST in range from DateTime.MinValue to DateTime.MaxValue, currently to speed up I'm calculating DST for range from 01.01.2000 to DateTime.Now - it is enough when converting value from database to UI, because in database the min date is on the 2008 year, but is not enough for html input, because user can select value greater than DateTime.Now and lower then 01.01.2000. To fix it I'm, planning with use of TimeZoneConverter send to client the IANATimezoneId, and for cases when provided date(UI or server) is not in the range [01.01.2000, DateTime.Now] belong on the moment.utc(date).tz(IANATimezoneId).isDST().
This is new code on the server side
private class DaylightSavingTimeDescriptor
{
public DateTime StartTime { get; set; }
public DateTime EndTime { get; set; }
public bool IsDaylightSavingTime { get; set; }
}
private string GetDaylightSavingTimeDescriptorsJson(string timeZone)
{
string daylightSaveingTimeDescriptorsJson = String.Empty;
if(timeZone != null)
{
List<DaylightSavingTimeDescriptor> dstList = new List<DaylightSavingTimeDescriptor>();
TimeZoneInfo timeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById(timeZone);
DateTime startDate = new DateTime(2000, 1, 1);
DateTime dateIterator = startDate;
bool isDST = timeZoneInfo.IsDaylightSavingTime(startDate);
while (dateIterator < DateTime.Now)
{
bool currDST = timeZoneInfo.IsDaylightSavingTime(dateIterator);
if (isDST != currDST)
{
dstList.Add(new DaylightSavingTimeDescriptor()
{
EndTime = dateIterator.AddDays(-1),
IsDaylightSavingTime = isDST,
StartTime = startDate
});
startDate = dateIterator;
isDST = currDST;
}
dateIterator = dateIterator.AddDays(1);
}
daylightSaveingTimeDescriptorsJson = Newtonsoft.Json.JsonConvert.SerializeObject(dstList);
}
return daylightSaveingTimeDescriptorsJson;
}
And this is modified dateToServer, dateToClient on client side
export default class DateService{
constructor (authService) {
const authData = authService.getAuthData();
this.clientTimeZoneOffset = Number(authData.timeZoneOffset);
this.daylightSavingTimeRanges = authData.daylightSavingTimeRanges ? JSON.parse(authData.daylightSavingTimeRanges) : [];
}
getDaylightSavingTimeMinutesOffset(utcDate) {
const dstRange = this.daylightSavingTimeRanges.find(range => {
const momentStart = moment(range.startTime).utc();
const momentEnd = moment(range.endTime).utc();
const momentDate = moment(utcDate).utc();
return momentStart.isBefore(momentDate) && momentEnd.isAfter(momentDate);
});
const isDaylightSavingTime = dstRange ? dstRange.isDaylightSavingTime : false;
return isDaylightSavingTime ? '60' : 0;
}
dateToClient(date) {
const momentDate = moment(date);
let uiDate = null;
if (momentDate.isValid() && date) {
const browserUtcOffset = momentDate.utcOffset();
uiDate = momentDate
.utc()
.subtract(browserUtcOffset, 'minutes')
.add(this.clientTimeZoneOffset, 'minutes')
.add(this.getDaylightSavingTimeMinutesOffset(momentDate.utc()), 'minutes')
.toDate();
}
return uiDate;
}
dateToServer(date) {
const momentDate = moment(date);
let serverDate = null;
if (momentDate.isValid() && date) {
const browserUtcOffset = momentDate.utcOffset();
serverDate = momentDate
.utc()
.subtract(this.clientTimeZoneOffset, 'minutes')
.add(browserUtcOffset, 'minutes')
.subtract(this.getDaylightSavingTimeMinutesOffset(momentDate.utc()), 'minutes')
.toDate();
}
return serverDate;
}
}
PS
I want to get rid off offsets and use moment-timezone on the client and timezone converter on the server, but it will be later if customer ask, because I have never tried it before and I'm not sure that it will be working well, and current solution is working. Also the offsets anyway will be used for dateinputs components (angularjs), because they are using kendo-dateinput which ng-model is JS Date in browser local time, but I'm providing another timezone so need to transformations inside component.
PPS Best solution from my point of view, if timezone converter and moment-timezone will be working as expected
Anyway the whole app is operating the JS Date, so when user in Moscow with America in profile selects the datetime in kendo-input, or see setup kendo-scheduler, or display the date in the kendo-table, I need to manipulate with offsets. But instead of passing directly the client offset, I'm planning to pass IANA timezone id from the server with help of timezone converter and get the offset I need directly from moment-timezone.
I have the following code:
$(function () {
var thedate = "/Date(1198908717056)/";
var thedate2 = ProcessDate(thedate)
alert(thedate2);
});
function ProcessDate(DateString) {
var TheDate = eval(DateString.replace(/\/Date\((\d+)\)\//gi, "new Date($1)"));
return TheDate;
}
When it runs, it returns an alert with December 29 and the time is showing as Eastern Time. When I change the timezone on my computer, it's still showing the date in the Eastern timezone.
My question is this: does the string "/Date(1198908717056)/" contain the timezone information or is the timezone displayed in the alert the result of the browser determining my timezone?
Thanks.
JSON doesn't have dates at all (it's one of JSON's flaws). Those strings are just strings.
Some frameworks, like ASP.Net, use that syntax to indicate dates. What timezone they're in will be dictated by the framework. I believe the dates are in UTC and so you can just use the new Date(Number) constructor to create them (more in this other answer). That creates the date by directly setting its internal "milliseconds since The Epoch UTC" value, more in section 15.9 of the specification. Mind you, that only works if, in fact, whatever it is creating these pseudo-date strings is using UTC.
Update: Looking at your code, although it works, this line:
var TheDate = eval(DateString.replace(/\/Date\((\d+)\)\//gi, "new Date($1)"));
...is an abuse of eval. eval should be avoided whenever possible. Instead, if you want to keep it as a one-liner:
var TheDate = new Date(Number(DateString.replace(/\/Date\((\d+)\)\//gi, "$1")));
...or somewhat more readably:
var Match = /\/Date\((\d+)\)\//gi.exec(DateString);
var TheDate;
if (Match) {
TheDate = new Date(Number(Match[1]));
}
In all of those cases, the Date will be initialized with the UTC time value embedded in the date string. But then when you ask JavaScript to format the date (for instance, via toString), it will use your local timezone to do that. You haven't shown how you're outputting the date, so I can't tell you why the timezone seems not to change if you change your timezone (perhaps the browser didn't pick up the change?). When I do it, if I output the date as a string, it shows it in British Summer Time (which is my current timezone) if I use toString, or UTC if I use toUTCString. Here's a live example using both your original date, and a date (today's date, as I write this) that's in daylight savings time so even in the UK you can see the difference between UTC and local time.
Off-topic: In JavaScript, the overwhelming convention is to use camelCased names starting with a lower-case letter for both local variables and function names. So, theDate rather than TheDate. Initial caps are reserved for constructor functions (like Date). You're free to ignore the convention, of course, but it will tend to make it difficult for others to read your code.
The timezone is taken from your current system setting. Have a look at the Date class.
The given value is in milliseconds and does not contain a timezone. The constructor of Date() expects the milliseconds to be given in UTC. If you have values with a known timezone, you should use the dateString constructor version.
However, as far as I know, there is no way convert between timezones in JavaScript, except for UTC and the local system timezone.