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.
Related
Used ng prime datepicker in application.
Getting date in Fri May 14 2021 00:00:00 GMT+0530 (India Standard Time) format as response from api.
Then converting Fri May 14 2021 00:00:00 GMT+0530 (India Standard Time) this response with new Date().
Then binding the response to ng prime datepiker.
Working fine in chrome.
In firefox it is showing "Invalid date".
See the documentation for the Date constructor:
A string value representing a date, specified in a format recognized by the Date.parse() method. (These formats are IETF-compliant RFC 2822 timestamps, and also strings in a version of ISO8601.)
Since you aren't passing one of those formats, you are dependent on implementations having non-standard support for your format.
Chrome does. Firefox doesn't.
Use a date parsing library that lets you specify the format (such as date-fns/parse) or change the API so it outputs dates in the standard format.
You can as well, use the dateStringToDate function in date-fran module. It converts date formats of the form "Fri May 14 2021" to actual date instances.
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.
If I pass the unix milliseconds timestamp value for 1/1/1753 (at midnight) (-6847786800000) to the JavaScript Date() constructor in Chrome, the Date Chrome gives me looks really weird. I get other weirdness when I use the Date() constructor that takes seven parameters. Examples are below.
Chrome: new Date(-6847786800000): Mon Jan 01 1753 00:03:58 GMT-0456 (Eastern Standard Time)
Firefox: new Date(-6847786800000): Mon Jan 01 1753 00:00:00 GMT-0500 (Eastern Standard Time)
Note how Chrome made the time 3:58 and the timezone GMT-0456 (the weird timezone appears to be about the same amount as the weird time (4 minutes).)
Chrome: new Date(1753, 0, 1, 0, 0, 0, 0): Mon Jan 01 1753 00:00:00 GMT-0456 (Eastern Standard Time)
Firefox: new Date(1753, 0, 1, 0, 0, 0, 0): Mon Jan 01 1753 00:00:00 GMT-0500 (Eastern Standard Time)
Note how Chrome gives me 0:00 for the time, but still has that GMT-0456 timezone.
Playing around with various dates, this odd behavior seems to start with dates before 1884 - not sure of the exact date. 1/1/1884 acts as you would expect, but 1/1/1883 gets this "off by 3:58" behavior.
Is this a bug or am I missing something?
I tested this on:
Chrome 67.0.3396.99 (Official Build) (64-bit);
Firefox 61.0 (64-bit);
IE 11 and Edge 42.17134.1.0 give the same results as Firefox
UPDATE
This does not look like a duplicate of Browsers, time zones, Chrome 67 Error to me. That question is talking about timezones being different. It uses 1900 as an example. I'm talking about the time being different. And it only affects stuff before 1884. It does not affect 1900 dates.
Why would changing the timezone change the actual time? I'm not a timezone wizard but that still seems wrong to me.
UPDATE
So yeah, probably a duplicate in some sense. Don't know for sure if Chrome changed it's behavior with this. But it does come down to the fact that right now Chrome will see old unix timestamps, before 11/18/1883 at 12:03:58 PM, as different points in time than other browsers. So watch out if you need to work with timestamps for old dates. I switched away from using timestamps to avoid this issue.
I'm experiencing a problem with Firefox on RedHat when obtaining the current time, but it only seems to occur when executed within the script tags of our website. For my local timezone (GMT +0000), daylight savings is applied correctly and Date() produces IST/BST (GMT +0100). But when I test this for other timezones (EDT in this example), Daylight Savings is not being accounted for
When the system time is set to Fri Aug 1 07:42:56 EDT 2014, running:
console.log(new Date());
within the script tags of the website returns:
Fri Aug 01 2014 06:42:56 GMT-0500 (EDT)
However, when executing "new Date()" in the Firefox console, or on a test html page, the value returned is correct:
Fri Aug 01 2014 07:42:56 GMT-0400 (EDT)
This problem doesn't occur on Windows either. I understand that the timezone offset is adjusted so that the time is technically correct, but I don't understand why it produces a different value when executed on our website. I'm completely perplexed.
Attempts so far:
"new Date(Date.now())"
Dojo date/stamp: "stamp.fromISOString(new Date().toISOString())"
"new Date()" at various different areas of the website code base
Many browsers, including FireFox, require you fully restart the browser after changing time zones in order to provide correct results. Closing all browser windows and restarting before testing again should fix the problem.
An exception to this is Internet Explorer on Windows, which subscribes to OS messages and resets correctly without restart.