I think I need clarification on something:
I have a string representing a date in a format like this:
'2013-12-24 12:30:00'
and if I pass it to Date(), then I get the following output
new Date('2013-12-24 12:30:00')
// --> Tue Dec 24 2013 12:30:00 GMT+0100
because iOS has problems with this, I read that I should use T as separator, however
new Date('2013-12-24T12:30:00')
// --> Tue Dec 24 2013 13:30:00 GMT+0100
the result adds one hour. I guess it has something to do with summer or winter, but what exactly does the T stand for, and why is the result different? I meanwhile solved my problem by passing separate parameters to the Date but I would still like to know where this extra hour is coming from.
new Date('2013-12-24T12:30:00')
treats the time as UTC, so it's 12:30 in Greenwich and 13:30 in your timezone.
new Date('2013-12-24 12:30:00')
is a Chrome extension (or bug) that doesn't work in other browsers. It treats the time as local, so it's 12:30 in your timezone (GMT+1) and 11:30 in Greenwich.
If you look closely... you will notice adding a T makes the time in 24-hour format.
new Date('2013-12-24T12:30:00')
// --> Tue Dec 24 2013 13:30:00 GMT+0100
Compared to
new Date('2013-12-24 12:30:00')
// --> Tue Dec 24 2013 12:30:00 GMT+0100
I guess its stands for Long time pattern. Refer this for more.
Related
When I run this code, the first date is shown in GMT, and the second in BST. Why is this? The calls to Date.UTC are identical apart from one changed digit, the month digit. That, to me, shouldn't warrant a change in timezone. Please note that I'm in London right now, so somehow the second date seems to be returning local time. Why is the timezone different for the two different dates?
var date1 = new Date(Date.UTC(2005,0,5,4,55,55));
alert(date1); // Wed Jan 05 2005 04:55:55 GMT+0000 (GMT)
var date2 = new Date(Date.UTC(2005,5,5,4,55,55)); // <-- 0 has been replaced by 5
alert(date2); // Sen Jun 05 2005 05:55:55 GMT+0100 (BST)
Using Date.UTC(), only effects setting the date using UTC.
As default Javascript dates display using localtime.
So if you wish to see the dates in UTC format,.
You can't just use the default toString() implementation, as that will use localtime version.
But what you can do is use the UTC variants for display. eg. toUTCString() and also toISOString().
var date2 = new Date(Date.UTC(2005,5,5,4,55,55));
//if you say live in the UK, this date in localtime is
//British Summer Time,..
//eg. Sun Jun 05 2005 05:55:55 GMT+0100 (GMT Summer Time)
//if your running this script from another country
//your likely to see something different.
console.log(date2.toString());
//here we show the date in UTC, it will be same
//whatever country your running this from
//eg. Sun, 05 Jun 2005 04:55:55 GMT
console.log(date2.toUTCString());
//for an easier to parse date,
//eg. 2005-06-05T04:55:55.000Z
console.log(date2.toISOString());
Please see the code example below from Google Chrome:
new Date('Thu Jul 27 2017 13:10:42 GMT-0500')
Result: Thu Jul 27 2017 19:10:42 GMT+0100 (BST)
new Date('Thu Jul 27 2017 13:10:42 GMT+0500')
Result: Thu Jul 27 2017 09:10:42 GMT+0100 (BST)
I would read the first date current time as being 13:10 which is -0500 hours off from GMT but the result it gives is +5 hours in the future +1 hour BST. In a similar vein the second date works the opposite way being +0500 hours off but returning -5 hours in the past +1 BST.
Firefox works in a similar way but it seems without the BST:
new Date('Thu Jul 27 2017 13:10:42 GMT-0500');
Date 2017-07-27T18:10:42.000Z
new Date('Thu Jul 27 2017 13:10:42 GMT+0500')
Date 2017-07-27T08:10:42.000Z
IE Edge gives me these results:
new Date('Thu Jul 27 2017 13:10:42 GMT-0500')
Thu Jul 27 2017 19:10:42 GMT+0100 (GMT Summer Time)
new Date('Thu Jul 27 2017 13:10:42 GMT+0500')
Thu Jul 27 2017 09:10:42 GMT+0100 (GMT Summer Time)
Can anyone help throw some light on this please?
EDIT - this is not a duplicate of 'Why does Date.parse give incorrect results?' because I am not using the parse() method explicitly.
Please note: I am trying to create a date object that is not in the same timezone as my browser.
If this is not possible I might have to solve my current problem with some basic math (current time +/- the timezone required) - shame if I cannot do this with a native JS Date object.
The default conversion of a Date instance to a string gives you the date and time in terms of the local timezone. If you're doing it in the browser console, you can't even rely on that, because the console itself is free to do whatever it wants. Firefox's console seems to extract the UTC representation; if you call
new Date('Thu Jul 27 2017 13:10:42 GMT-0500').toString()
instead you get the local time.
Dates are based on the idea of UTC timestamps and the notion that local time is generally important. Creating a date from a string gives you a timestamp meaningful (well, as meaningful as possible) for the string, but subsequently the Date instance is by default treated as something relevant to the local context. You can always use the UTC APIs to extract the UTC time if you want.
This question seems to stem from unfamiliarity either with how date strings are parsed by the built–in parser or with how they are formatted by various built–in toString methods.
The same parser is used by Date.parse and the Date constructor, it doesn't matter which is used in terms of how the string is parsed to a time value. The only difference between the two is that Date.parse returns the time value as a number, whereas the Date constructor uses the time value to create a Date instance (which is the only value that a Date instance holds).
The time value itself is milliseconds since 1970-01-01T00:00:00Z, so has no time zone (and means Date instances are effectively UTC). The value returned by getTimezoneOffset and the timezone displayed in toString methods (if there is one) is from the host system, it's not a property of Date instances or the Date constructor.
The timestamp pairs in your question represent exactly the same moment in time, but in different time zones.
Thu Jul 27 2017 13:10:42 GMT-0500 is Thu Jul 27 2017 18:10:42 GMT.
Thu Jul 27 2017 19:10:42 GMT+0100 (BST) is also Thu Jul 27 2017 18:10:42 GMT.
The value returned by Date.prototype.toString is entirely implementation dependent. When you send a date to output, the host may use any method it likes to represent the Date and may format it any way it wants. In the above, it seems the host timezone (UTC+0100) has been used with the default toString, which may return a differently formatted string in different implementations.
However, recent browsers seem to have settled on RFC 2822 format. Other methods that typically return different formats are toISOString and toLocaleString (noting that all three methods could return an ISO 8601 format string and be consistent with the ECMA-262, though I don't know of any implementations that do).
The next two dates also represent exactly the same moment in time:
Thu Jul 27 2017 13:10:42 GMT+0500 is Thu Jul 27 2017 08:10:42 GMT
Thu Jul 27 2017 09:10:42 GMT+0100 (BST) is also Thu Jul 27 2017 08:10:42 GMT
Again, the host timezone has been used to generate the output string.
As for "Firefox works in a similar way but it seems without the BST", see above. ECMA-262 only requires the the format be convenient and human readable. In this case, the browser developers have chosen to use an ISO 8601 format with no offset (i.e. UTC+0000).
So:
Thu Jul 27 2017 13:10:42 GMT-0500 is Thu Jul 27 2017 18:10:42 GMT+0000
2017-07-27T18:10:42.000Z is also Thu Jul 27 2017 18:10:42 GMT+0000
The choice not to use a timezone offset is entirely up to the browser developers and is consistent with ECMA-262.
If your issue is with how date strings are parsed, the duplicate is Why does Date.parse give incorrect results?. If it's with how dates are formatted, the duplicate is Where can I find documentation on formatting a date in JavaScript? The answers to those two questions should answer any issue raised in the OP.
Would someone explain why formatting the same dateString differently gives a different date?
> new Date("04/08/1984")
<· Sun Apr 08 1984 00:00:00 GMT-0600 (Mountain Daylight Time)
> new Date("1984-04-08")
<· Sat Apr 07 1984 18:00:00 GMT-0600 (Mountain Daylight Time)
When you create a new Date object passing a dateString parameter to the constructor, it gets parsed using the Date.parse() method. Now, quoting from the MDN documentation (emphasis mine):
Differences in assumed time zone
Given a date string of "March 7, 2014" (or "03/07/2014"), parse() assumes a local time zone, but given an ISO format such as "2014-03-07" it will assume a time zone of UTC. Therefore Date objects produced using those strings will represent different moments in time unless the system is set with a local time zone of UTC.
Therefore, since that your are giving the second string in the ISO format, and your local time zone is UTC+6, you're getting a date which is six hour behind yours, because it gets calculated as UTC+0. In fact:
Apr 07 1984 18:00:00 = Apr 08 1984 00:00:00 - 06:00:00
Mystery solved!
Your problem is that you are adding 0 before the numbers in "1984-04-08". Try the following:
new Date("1984-4-8")
document.write(new Date("04/08/1984"));
document.write("<br>");
document.write(new Date("1984-4-8"));
I have noticed a peculiar behavior when converting strings to Date objects in javascript. When doing this:
var date1 = new Date("2014-09-28T00:00:00");
console.log(date1);
The result is:
Sun Sep 28 2014 02:00:00 GMT+0200 (Srednja Europa - ljet. vrij.)
The same code with another date.
var date2 = new Date("2014-10-28T00:00:00");
console.log(date2);
gives this result:
Tue Oct 28 2014 01:00:00 GMT+0100 (Srednja Europa - st. vrij.)
Notice that the GMT offset in the first variable is 2 hours and in the second just 1 hour. The first one takes the summertime time calculation in account and the second one does not. Can anybody explain this? Have to mention that I am from Croatia where the current GMT offset is plus two hours and summertime is on.
According to timeanddate.com, Daylight Saving Time (DST) in Croatia ends on October 26th, 2014. Therefore, the first date (September 28th) includes it (GMT+2), and the second (October 28th) does not (GMT+1).
I'm creating dates from strings with the format 'yyyy-MM-dd' but they're always created on the previous day for some reason. If I set the date as '2012-10-31' the Date object with actually be 30 of October and not 31. For example, this:
var d1=new Date('2012-10-31');
Will output this:
Tue Oct 30 2012 19:30:00 GMT-0430 (Venezuela Standard Time)
Can someone explain why this happens?
With no further parameters, Date() create your time-stamp with GMT+0000.
Converting your date to string with no further parameters either, it will use the localised notation.
If you want to create a date matching your time-zone, do:
var d1=new Date('2012-10-31 GMT-0430');
//That's what you should get
//"Wed Oct 31 2012 00:00:00 GMT-0430"
Using this date now, you can convert the local time to the time of other timezones if you execute d1.toString() in a browser with a different timezone:
d1.toString();
//That's what I get
//"Wed Oct 31 2012 05:30:00 GMT+0100"
Try this
var d1=new Date(2012, 10-1, 31, 0, 0 ,0);
document.write(d1);
which produces
Wed Oct 31 2012 00:00:00 GMT-0400 (Eastern Daylight Time)
the key is to remove the quotes and manually set the time. Also note that 'month' is zero based and so for readability I subtract one from it
This happens because dates are converted to a string based on your local time zone.
The date variable actually contains October 31st 0:00 UTC. When you convert it to string, it is converted using your own time-zone, which is 4:30 hours behind UTC.