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?
Related
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.
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.
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 )
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.
I have 2 Samsung Smart TVs with the following model and firmware (from TV Menu->Support->Contact Samsung screen)
2013:
Model Code: UN32F5500
Software Vesrion: T-MST12AKUC-1121.3
2014:
Model Code: UN40H6350
Software Vesrion: T-MST14AKUC-1115.3
The first problem (reproduced on both TVs, 2013 & 2014) is the timezone is detection is wrong. The following code:
<script type='text/javascript' src='./$MANAGER_WIDGET/Common/af/../webapi/1.0/deviceapis.js'></script>
// ...
var timezone = deviceapis.tv.info.getTimeZone();
window.alert('Timezone=' + timezone.timezone + ', dst=' + timezone.dst);
outputs the following:
Timezone=2, dst=0
This is PL_TV_TIMEZONE_EASTERN whereas I'm in the PST timezone, i.e. the following output is expected (5 is PL_TV_TIMEZONE_PACIFIC, and daylight savings time is active now):
Timezone=5, dst=1
The most weird thing is that I'm not able to change the TV's timezone and DST setting. If I go to the TV's Menu->System->Time->Clock, then the 'DST' and 'Time Zone' settings are disabled (grayed out) even if the 'Clock Mode' setting is set to 'Manual'.
The second problem is specific for the 2014 TV, it's not reproduced on the 2013 TV. The Date's getUTCHours() method returns wrong result not taking into account Daylight Saving Time Shift. That is, the following code:
var now = new Date();
window.alert('now: ' + now + '; getUTCHours()=' + now.getUTCHours());
produces the following output:
now: Fri Aug 08 2014 18:12:52 GMT-0800 (GMT), getUTCHours()=2
whereas the following is expected (as on my 2013 TV):
now: Fri Aug 08 2014 18:12:52 GMT-0700 (PDT); getUTCHours()=1
The current time (Fri Aug 08 2014 18:12:52) is correct but the DST offset is not taken into account in the returned GMT time's hour. Also, timezone code in the parenthesis is wrong (GMT instead of PDT or rather, taking into account timezone error described above, EDT or EST).
I observed this problem just recently, I think it appeared after I made Software Update for the 2014 TV. I'd rather think this is a bug introduced in the latest version of the firmware.
I tried to use TV plugin's (clsid:SAMSUNG-INFOLINK-TV) GetDST(), GetTimeZone(), GetTimeZone_Offset() functions, but all of them return incorrect results.
I'd very appreciate any help provided.
Thank you!
I just contacted Samsung support, and they suggested that the Input had to be set to "TV" before entering setup to have access to the Timezone and the other parameters.
Well, it absolutely sounds like a firmware problem to me. I'd consider taking it up with their technical support. (Good luck.)
If time zone issues are important for your app and you're looking for a workaround, consider providing your own time zone data with your application. Assuming you can run any JavaScript you want, you should be able to use moment.js with the moment-timezone add-on.
Samsung supplied me with a link for my model that had me reset the Country Code to Virgin Islands, US, then back to US.
This resets the apps & Timezone/date.
This fixed the issue for me.
If you have different models, you might want to contact Samsung Chat to get a link for yours.
How to reset Country Code (Timezone) on my model per Samsung
http://support-us.samsung.com/cyber/popup/iframe/pop_troubleshooting_fr.jsp?idx=428459&modelname=UN55F6300AF&modelcode=UN55F6300AFXZA