So what I am doing is typing into the dev console this line of javascript new aDate = new Date().toString(). When I am on google.com it returns me this Mon Mar 7 17:50:15 PST 2016, but when I go to my local site and do the same thing I get the UTC format Mon Mar 07 2016 17:50:52 GMT-0800 I need the value in local time like what I see when I am on google.com. Is anyone aware of this issue before? I am only getting this in IE 8 and 9, but 11 is ok. I think this happens after someone added the ECMAScript 5, which I believe maybe changing the javascript date time object. I know that Micorosoft stopped supporting anything lower then 11, but we still need to support 8 and 9 until our customers are done migrating. Any help/direction would be appreciated.
If you want to display same time format regardless of browser, try using Moment.js ( http://momentjs.com )
Related
Normally new Date() returns the time, time-zone and region, like Thu Sep 02 2021 15:04:30 GMT+0800 (Taipei Standard Time), but for some reason two of my colleague's computer isn't returning the region, and only shows something like Thu Sep 02 2021 15:04:30 GMT+0800 (GMT+8).
I originally discovered this because when we use moment-timezone's moment.tz.guess(), it returns Etc/GMT-8 instead of Aisa/Taipei, and thought it might have something to do with the browser not being able to get the user's location, as mentioned in moment.js' official docs.
We're sure it's not a browser issue though, since we've tested it on Edge, Chrome and Firefox.
Any ideas on why this happens?
Ok we tested it out, and it IS an issue with the OS's settings.
So the computers' regions are both initially set to Taiwan, and what we did was we tried setting it to elsewhere, then setting it back again. And...for some reason that did the trick.
Weird, but I guess strange things just happens on Windows.
But thanks for all the replies! Hopefully this can help another confused user in the future...
In the Australia/Sydney time zone, Firefox seems to give an incorrect time for toLocaleString on dates:
new Date("2019-04-04T01:12:38.553309+00:00").toLocaleString() gives "4/4/2019, 11:12:38 AM".
new Date("2019-04-04T01:12:38.553309+00:00").toString() gives correct result "Thu Apr 04 2019 12:12:38 GMT+1100 (AEDT)".
I've been able to reproduce this on my phone as well as my computer. I asked a colleague to test, and Firefox gave the correct output on his computer.
Chromium gives the correct time for toLocaleString.
Is this a bug in Firefox? Do I have some misconfiguration?
I assume the correct approach here is to use a 3rd party library like date-fns to format my Dates instead.
Update: for now I have switched to using dateFns.format(timestamp, 'yyyy/MM/dd HH:mm:ss'). We don't have any US customers anyway.
Strange thing, different results in differente browser for a new Date().
In Chrome 45.0.2454.101 m:
new Date(2015,9,1)
Thu Oct 01 2015 00:00:00 GMT+0200 (W. Europe Daylight Time)
In Firefox 40.0.3 (default inspector/console)
new Date(2015,9,1)
Date 2015-09-30T22:00:00.000Z
Additional info
If I try in Firefox with the console of FIREBUG extension, works well like Chrome.
What's happening? Seems that Firefox doen'st count the offset, in fact it's 2 hour behind the correct date.
I did the test on other workstation and all seems to have this "bug".
IF you don't want the timezone offset to be included you can use Date.UTC
Note: Where Date is called as a constructor with more than one
argument, the specifed arguments represent local time. If UTC is
desired, use new Date(Date.UTC(...)) with the same arguments.
~MDN
Output from Firefox dev console:
> new Date(2015,9,1)
Date 2015-09-30T22:00:00.000Z // reproduces your problem, my local time is GMT+0200
> new Date(Date.UTC(2015,9,1))
Date 2015-10-01T00:00:00.000Z // UTC time
However 00:00:00 GMT+0200 and 22:00:00.000Z are just different ways to represent the timezone offset in Date's string representation. The difference is the method used when printing to console: most browsers use .toString() while Firefox uses .toISOString(). (Edited; previously stated that the toString method implementations are different which isn't true).
In both Chrome (Thu Oct 01 2015 00:00:00 GMT+0200) and Firefox (Date 2015-09-30T22:00:00.000Z) methods like .getDate() and .getMonth() return the same values (1 and 9 respectively). The Date objects are the same.
This is just the behavior of the debug console. The two date values you showed are both the same, and are the correct value. You're just seeing the local time in Chrome, while Firefox chooses to show the UTC time in the debug console.
More accurately, Chrome, IE, and most other browsers simply call .toString() on the object, while Firefox is calling .toISOString().
Note that Firefox has a bug that us showing the wrong name of the time zone (Standard instead of Daylight), but you can see the debugger value matches the ISO8601 UTC value.
On the console in chrome browser of windows and Ubuntu I entered Date() object and I found both have a different way to write the timezone for that date.
Ubuntu:
"Thu Aug 10 2017 18:45:18 GMT+0530 (IST)"
Windows:
"Thu Aug 10 2017 18:45:18 GMT+0530 (India Standard Time)"
According to my use case the output on Ubuntu is correct, the time zone IST is what expected. But on windows it always shows up India Standard Time.
Is there a way to fix this for windows.
According to my use case the output on Ubuntu is correct
Neither of them is correct. Or incorrect. The string form of a Date from toString (which is what those appear to be) is almost completely unspecified. The only requirement is that it represent the date, and that Date() and Date.parse should be able to parse it.
If you want something reliable cross browser*, use toISOString.
* Obsolete browsers may not have toISOString. Even only vaguely-modern browsers do.
Windows browsers (IE, Chrome, Firefox) are not respecting the old US daylight saving time rules for dates prior to 2007. Using a machine set to Eastern Time, the following javascript call returns an incorrect time:
(new Date("03/15/1993")).toGMTString();
returns:
Mon, 15 Mar 1993 04:00:00 GMT <-- Incorrect
should be:
Mon, 15 Mar 1993 05:00:00 GMT <-- Correct
Chrome and Firefox for OSX return the correct value so it appears to be an issue with browsers making a Windows API call.
The DST rule changes are:
- Prior to 2007: 1st Sunday in April until Last Sunday in October
- After 2007: 2nd Sunday in March until 1st Sunday in November
It appears that Windows is applying the current rules for dates prior to 2007. In my case, I have a Javascript framework that communicates with our server side (Java) framework using full GMT time. Java is applying the CORRECT rules, so in the case of the above date, the server is interpreting the incorrectly submitted time March 14th 1993.
Same submission from all browsers in OSX is working correctly.
Has anyone experienced anything like this or know of any workaround?