I have just cast a 08/23/2012 to date in javascript:
var value = '08/23/2012';
var newdate = new Date(value);
newdate happens to be Date {Thu Aug 23 2012 00:00:00 GMT+0100 (BST)}
I live in London (GMT 0:00) so where does the +1 assumption come from and how can I set it right?
You're in the Europe/London timezone, with is GMT+0100 during the summer, due to the Daylight Saving Time scheme.
This is why it's usually better to configure systems based on the location, and adapt the timezone by looking up the tz database. Unfortunately, JavaScript implementations in browser are quite poor regarding the general handling of time zones.
London is currently GMT+1 because of Daylight Savings.
If you want dates unaffected by timezones or DST, you need to do two things:
Define dates with a timestamp. A timestamp is a number of milliseconds since the Epoch, and is completely agnostic with regards to timezones and DST
Use the Date.getUTC___() functions to get the date and time in UTC, which is basically GMT but without the daylight savings.
Related
In javascript, I have a date in UTC, and I want to stringify it and parse it but maintain it's UTC. I did this code
var f = { f : new Date("Mon May 27 2019 20:11:13 GMT-0400 (Eastern Daylight Time)")}
undefined
JSON.stringify(f)
"{"f":"2019-05-28T00:11:13.000Z"}"
JSON.parse(JSON.stringify(f))
{f: "2019-05-28T00:11:13.000Z"}
You can see that after I stringified it, it changed to the next day. And then when I parse it, it kept it as a string and even of the next day. I want it so that after I parse it, I get back the Date object of Mon May 27 2019 20:11:13 GMT-0400 (Eastern Daylight Time).
Does anyone know what's wrong?
Thanks
You can see that after I stringified it, it changed to the next day
No, it didn't. "Mon May 27 2019 20:11:13 GMT-0400 (Eastern Daylight Time)" was parsed to a time value of 1559002273000, which defines a moment in time that is that many milliseconds after 1970-01-01T00:00:00Z. It's equivalent to 2019-05-28T00:11:13.000Z (and other timestamps in other time zones). E.g. on a system set to an eastern Australian timezone you'd get "Tue May 28 2019 10:11:13 GMT+1000 (AEST)".
I want it so that after I parse it, I get back the Date object of Mon May 27 2019 20:11:13 GMT-0400 (Eastern Daylight Time)
The date object has no knowledge of the timezone of the original timestamp, it just stores the time value. The string produced by toString just uses the host system timezone setting to generate a "local" timestamp in the format specified by ECMA-262. Note that the timezone name is implementation dependent and since they aren't standardised, the names and abbreviations differ between implementations. E.g. Safari shows "AEST" and Firefox "Australian Eastern Standard Time".
You can use toLocaleString to generate timestamps for different timezones, but the date object doesn't know what the original timezone was and the format may not be what you want.
Also, toLocaleString uses IANA timezone identifiers (e.g. Africa/Kinshasa), which relate to geographic locations that are used to deduce the applicable timezone rather than common names like "Eastern Daylight Time" which are not standardised and can be ambiguous or obscure. The IANA designators mean things like daylight saving and historic timezone offset changes can be applied more easily than with other designators.
I am investigating an issue involving the conversion of serialized UTC dates in to JavaScript date objects; I have read a few questions on this topic already but I am still unclear.
Firstly let me say that I am in the UK. If I take for example the UTC epoch 1473805800000, which is Tue, 13 Sep 2016 22:30:00 GMT, then use that value to create a JavaScript date:
var date = new Date(1473805800000);
console.log(date);
The console logs:
Tue Sep 13 2016 23:30:00 GMT+0100 (GMT Summer Time)
I.e. the browser has recognised that an extra hour needs to be added for DST.
My question is, if I were to run this same code again after the 30th October when the clocks have gone back, would I still get the same result of 23:30, or would it be 22:30 as if it were GMT? In other words, has the browser added an hour because the subject date is DST or because we are currently in DST?
I'm prevented from altering my work station's system clock by group policy, otherwise I would skip it forward in time and test this myself.
Javascript Date objects use a time value that is an offset in milliseconds since 1970-01-01T00:00:00Z. It is always UTC.
If the Date constructor is given a single number argument, it is treated as a UTC time value, so represents the same instant in time regardless of system time zone settings.
When you use console.log(date), the built–in toString method is called which generates an implementation dependent string, generally using the current time zone setting of the host system to create a convenient, human readable string.
The current daylight saving rules in the system are used to determine the offset to use for "local" time, so if the date changes from a time when daylight saving applies to one when it doesn't, the time zone offset will be similarly adjusted (note that daylight saving offsets aren't always 1 hour). It does not matter what the current system offset is, the one used is based on the setting for the date and time that the time value represents.
Also, Date objects are very simple, they're just a time value. The time zone offset comes from system settings, it's not a property of the Date itself.
So, given:
My question is, if I were to run this same code again after the 30th
October when the clocks have gone back, would I still get the same
result of 23:30, or would it be 22:30 as if it were GMT?
the answer is "yes", it will still be 23:30 since on 13 September BST applies. It doesn't matter when the code is run, only what the system offset setting is for that date.
In your case, the Date was created using epoch 1473805800000 and converted to your timezone GMT+0100. Epoch is always UTC time, therefore it was read as UTC and converted to your current timezone.
On September 13 2016, GMT+01 had summer time, therefore it was considered in the calculus.
In my case, I get the following, running the same code as yours:
Thu Sep 15 2016 14:13:14 GMT-0300 (E. South America Standard Time)
Let's say I create a new Date(), log it to the console, and see:
Date.toString() = Sun Sep 27 2015 00:00:00 GMT+0100 (GMT Daylight Time)
This tells me that the date is Sept. 27th, 2015, and my timezone is an hour ahead of UTC.
Now let's say I serialize this Date by calling toISOString() on it. The result of toISOString() is:
2015-09-26T23:00:00.000Z
Now let's say I send this toISOString() value off to a server.
Am I correct in asserting that the server receiving only the 2015-09-26T23:00:00.000Z cannot know that the original Date on the client browser was the 27th, not the 26th?
(In other words, the timezone offset would also need to be sent to the server to know the Date was for the 27th.)
yes, you are correct in that, but you could guess the timezone based on the ip address.
I'm logging out the following....
dbResponseStub.startTime = new Date(2014,6,13);
console.log(dbResponse[0].startTime);
console.log(new moment(dbResponse[0].startTime).utc().format());
But I am getting...
Fri Jun 13 2014 00:00:00 GMT+0100 (BST)
2014-06-12T23:00:00+00:00
I'm confused because the second one is an hour behind what it should be. Obviously the BST thing that happens in the first one is causing a problem. Anyone know how to turn this off in node so that what time i say it is it will be?
Dates are given in local time.
The first one has BST in it because it is showing you the time zone, and that is the time zone the computer is configured to use.
British Summer Time is an hour ahead of Coordinated Universal Time.
If you want to stay in BST then remove .utc() so you don't convert to it.
var date = new Date(1257397200000);
document.write(date);
Ran the code above I got Wed Nov 04 2009 23:00:00 GMT-0600 (Central Standard Time)
I am looking for a way to create date object based on different time zone, say for that time stamp I want to obtain date object like Thursday, November 5th 2009, 00:00:00 (GMT -5).
Note that the dates are different according to above two time zones, though they represent same point in time. I am in CST, is that why the created object is generated using CST?
Thank you.
No, these dates aren't different as they don't represent different point in time. The both represent Thu, 05 Nov 2009 05:00:00 GMT.
Date object in JavaScript is time-zone independent, it only represents point in time. The fact that Date.toString() includes time zone is very misleading, there is no time-zone information in Date. It is only a wrapper around milliseconds since epoch.
The time zone you see is based on OS/browser locale. You cannot create Date object in different time-zone. Consider using getUTC*() family of methods to get browser time-zone agnostic values.
BTW your example code prints:
Thu Nov 05 2009 06:00:00 GMT+0100 (CET)
on my computer - and this is still the same point in time.
See also
Annoying javascript timezone adjustment issue