Can someone explain to me why if I paste the following into the consoles of both Chrome and Firefox I get different results
new Date("2014-12-01")
Output in Chrome:
Sun Nov 30 2014 18:00:00 GMT-0600 (CST)
Output in Firefox:
Date 2014-12-01T00:00:00.000Z
Yes, you're reading that correctly. Chrome renders it as a day before.
Each browser will show dates in the console like it wants.
In your case, Firefox seems to use Date.prototype.toISOString under the hood:
new Date("2014-12-01").toISOString(); // "2014-12-01T00:00:00.000Z"
And Chrome seems to use Date.prototype.toString. In my case, on Chrome and in my timezone, I get
new Date("2014-12-01");
// Mon Dec 01 2014 01:00:00 GMT+0100 (Hora estándar romance)
new Date("2014-12-01").toString();
//"Mon Dec 01 2014 01:00:00 GMT+0100 (Hora estándar romance)"
However, note that Chrome does not render it as a day before. It's just that it uses GMT-0600:
Date.parse("Sun Nov 30 2014 18:00:00 GMT-0600 (CST)"); // 1417392000000
Date.parse("2014-12-01T00:00:00.000Z"); // 1417392000000
I think the Chrome's reading has to do with your locale settings as it converts the GMT entry to your time zone and makes the necessary adjustments whether subtracting, adding, or leaving it as is.
Related
Starting Chrome 67 (full version is 67.0.3396.87), I am experiencing weird behaviour with creation of a new Date object. Smallest reproducible case, goes something like:
<html>
<body>
<script> alert(new Date(-62135596800000)); </script>
</body>
</html>
On Firefox 60.0.2 the alert message is:
Mon Jan 01 0001 00:00:00 GMT+0000 (GMT Standard Time)
On Internet Explorer 11 and Edge 41.16299.461.0, the alert message is same as Firefox:
Mon Jan 01 0001 00:00:00 GMT+0000 (GMT Standard Time)
However, on Chrome 67 I see:
Sun Dec 31 0000 23:58:45 GMT-0001 (Greenwich Mean Time)
Edit: JsFiddle
Edit2 Turns out it's nothing to do with Microsoft's library.
Depending on the response to that bug report, I think this is actually due to Chrome possibly including IANA timezone information. Browsers, time zones, Chrome 67 Error
For example, when I run that fiddle, I get Sun Dec 31 0000 18:09:24 GMT-0550 (Central Standard Time) which corresponds to the IANA entry Zone America/Chicago -5:50:36 - LMT 1883 Nov 18 12:09:24.
So this is a "feature" not a bug I think. They are using the more "accurate" historical time offsets instead of current day time offsets for historical dates.
You can view the data here : https://github.com/eggert/tz just look for your appropriate world location file and try and avoid all the commented out lines unless you are morbidly curious about the history of your time zones.
What you can do to "fix" it so it display more or less correctly is to call .toUTCString() on the Date object which will force it to UTC time and display Mon, 01 Jan 0001 00:00:00 GMT as #Pointy pointed out in the comments on the initial question.
Your code, as long as MS's one, doesn't know anything about the timezone, so I assume Chrome takes the default one.
I guess it should be better if you create your date as below:
const date = new Date(Date.UTC(year, month, day, hour, minute, second));
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.
I'm having trouble with firefox converting date object to date string.
Here is the piece of my JS code:
var dt = Date('2014-05-10');
alert(dt.toString());
My timezone on my PC is set to Eastern Time Zone.
This is what I am getting using different browsers:
Firefox:
Wed May 14 2014 10:13:52 GMT-0400 (Eastern Standard Time)
Chrome:
Wed May 14 2014 10:14:30 GMT-0400 (Eastern Daylight Time)
IE:
Wed May 14 10:15:14 EDT 2014
Any idea why I am getting EST on Firefox?
My dev environment is in mac.
I use bootstrap datepicker to choose dates in an application.
When a day like 27/11/2013 is selected in mac when I debug, the screen shows...
day: 1385510400
and the translation to an date object in the same debug tool is,
Wed Nov 27 2013 00:00:00 GMT+0000 (GMT)
which is correct.
All is OK, since here.
I upload the code to a windows environment and open the same page with IE8.
Start the nightmare... :)
In windows, the same day variable is shown like that...
day: 1385506800
and the translation to an date object in the same debug tool is,
Wed Nov 27 2013 00:00:00 GMT+0000 (GMT)
which, is not correct?
If we go to a external tool, the day that gave IE8 is day before, and the translation should be,
Tue, 26 Nov 2013 23:00:00 GMT.
How I can understand this?
There is no relation with the timestamp and the translation to date object, and obviously I can't find a way to make this works in both systems.
Could you wake me up from this nightmare?
Sorry for my english!
Fiddle
In JS in Chrome:
new Date(1385510400000) : Wed Nov 27 2013 01:00:00 GMT+0100
new Date(1385506800000) : Wed Nov 27 2013 00:00:00 GMT+0100
new Date("11/27/2013") : Wed Nov 27 2013 00:00:00 GMT+0100
Please note the order of the date string, it is in US order
Also note the 000 at the end; JS timestamps are in milliseconds
The same in IE8
Wed Nov 27 01:00:00 UTC+0100 2013
Wed Nov 27 00:00:00 UTC+0100 2013
Wed Nov 27 00:00:00 UTC+0100 2013
So exactly the same dates, on hour difference on the first
If you subtract the 1 hour from all dates, you get midnight on the first and 11pm on the 26th on the rest
To normalise you can do
var d = new Date(1385510400000);
d.setHours(0,0,0);
or change to UTC
I am working with JavaScript date's being returned from ASP.net which is of course that really strange /Date(1328261701393)/ thing.
So I am parsing it out and doing...
var date = new Date(1328261701393);
console.log(date.toString()) // Fri Feb 03 2012 03:35:01 GMT-0600 (Central Standard Time)
When I change my system clock to EST, I get...
Fri Feb 03 2012 04:35:01 GMT-0500 (US Eastern Standard Time)
I THINK I understand why this is, but I am not entirely sure...
Also, I noticed that when I pass in an actual date string like...
console.log(new Date("2/1/2012 2:45:53 PM").toString());
I get the same time on both EST and CST...
Wed Feb 01 2012 14:45:53 GMT-0600 (Central Standard Time)
Wed Feb 01 2012 14:45:53 GMT-0500 (US Eastern Standard Time)
This all sort of makes sense, I was just looking for the WHY?
Javascript gives the time as per time zone of the browser. So, when you change your system clock, the time difference between your machine time and GMT changes. This difference is appearing in figures after GMT
You should use DateTime.ToUniversalTime() method to get UTC time, otherwise .NET will use server's current timezone.
http://msdn.microsoft.com/en-us/library/system.datetime.touniversaltime.aspx
Timestamp (like 1328261701393) is timezone independent,
Datetime(like 2/1/2012 2:45:53 PM) is timezone dependent.