Develop Reference

Javascript gives different timezone on the same machine

The google chrome console is returning different timezones if I initialize the Date with a parameter or not.
In another machine the same code give me the right result:
It's weird but it's happening

I assume is Daylight Savings Time (DTS).
As it seems from the logs, the computers are not in the same location, and it seems that in Brazil, DTS is adopted regionally, applicable at the beginning of November.
A quick way to test if this is true, try creating an October date instead of November.

Wrong locale time in Android webview

We have an android app which more or less constists of only a webview, displaying a webapp. At some point, we want to display some timestamp to the user and use the following code
let dateString = new Date().toLocaleTimeString();
The problem is, this always produces a 12h time representation (ie with AM/PM, for instance 3:15 PM instead of 15:15), even if we set the device to use 24h clock (and the device does respect this setting, because we see the correct time in the statusbar). We also set the device to use German language and removed the english language settings. No luck either. The device locale is used, as our app is shown in the correct language, but the timestrings are still wrong.
window.navigator.language -> "de-AT"
new Date().toLocaleTimeString(); -> "6:10:13 PM"
new Date().toLocaleTimeString(window.navigator.language); -> "18:10:32"
At a first glance, the last line seemed as a possible workaround, but if language is for instance "en-US" this will always return 12h format, regardless whether the os is configured for using 24h clock or not.
I'm aware of this question, which seems somehow related to this issue, but the answers don't work for us.
Using various virtual devices I found out, it still works correctly on chrome 58 (on API 26) but does not work any more on chrome 61 (on API 27). Currently testing at chrome 70 beta, the problem still persists.
It's also important to note, that it works correctly in chrome itself (ie if I display a time stamp in a test website, it uses the system settings), but only fails in the webview.
Our current workaround is to generate timestamps via native app, but that seems rather clumsy.
UPDATE
I know I can do some things on the webapp side like overriding toLocaleTimeString (which in fact, I already did to get the correct format from the native app).
My question is more about: Is there any known changed behaviour (and maybe a setting to reverse this) in the native WebView which causes this issue to happen, because this works/worked like a charm on devices with Chrome <= 58.
In the meantime I filed an issue with chromium, they were able to reproduce it. Maybe this will get fixed in one of the next versions ...
UPDATE 2
The issue is already fixed on google's side and may be rolled out with some future update. In the meantime I will continue to use my current override of toLocaleTimeString() which calls back to the native app ...

Please try overriding the function Date.prototype.toLocaleTimeString
let f = Date.prototype.toLocalString;
Date.prototype.toLocalString = function(){
let s = f();
//since the method fails for US-locale manupulate s as required when locale is US and system is set to show 24 hr
// if ends with AM - just delete "AM"
// if ends with PM - add 12 to hr and delete "PM"
return s;
}
---please avoid directly modifying prototype of inbuilt JS objects---
let me also point out that it is not advisable to play with inbuilt object of JS as it may break or interrupt execution of some external libraries. So better create a new object and modify prototype of that object - use prototypical inheritance.

Chrome cannot get TimeZone name correctly after changing the TimeZone of computer

I have a snippet code in javascript as shown below:
$(document).ready(function () {
var day1 = new Date();
});
Now I open a browser (in this case I use FireFox) and the current TimeZone of my computer is UTC +10:00 Hobart. Then I view the day1 javascript variable in debug mode, it displays its value as image shown below.
The TimeZone name of UTC+10:00 Hobart is Tasmania Standard Time. FF gets the correct name and as my expected too.
Next, I will chang the TimeZone on my computer to UTC+10:00 Canberra, Melbourne, Sydney while FF browser is being opened. Then I refresh FF browser by pressing Ctrl+F5 and view day1's value in debug mode again.
As you can see, FF updated the new correct TimeZone name as AUS Eastern Standard Time. It worked as my expected too.
MS Edge and IE worked as the same way with FF.
BUT, Chrome worked in a different way.
The new TimeZone name that Chrome returns to me is Local Daylight Time, not AUS Eastern Standard Time as my expected and as the other browsers (FF, MS Edge, IE) did.
Why does not Chrome return "AUS Eastern Standard Time" name?
Is there any way can solve this case for Chrome?

Unfortunately, the implementation of time zone name is not standardized. The ECMAScript spec allows it to be anything the vendor wants it to be. It's not even just different across browsers, but also across different versions of the browser, and across operating systems.
From ECMA-262 (5.1) Section 15.9.5.2 (emphasis mine)
Date.prototype.toString()
This function returns a String value. The contents of the String are implementation-dependent, but are intended to represent the Date in the current time zone in a convenient, human-readable form.
If what you're trying to do is to detect the user's time zone, there is a newer standard for retrieving the time zone name, as an IANA time zone identifier (ex, Australia/Sydney), which you can do like this:
Intl.DateTimeFormat().resolvedOptions().timeZone
However, not all browsers have implemented this yet. There are libraries that can guess at it though, which you can read about here.

What can make Date.parse return different values?

I have a slight difference on two machines with the same parameter for Date.parse function.
I run javascript:Date.parse('11/10/2014 00:00:00 AM') (month/day/year time) on the address bar of IE (10 and 8) and FF (latest) and the result is:
Machine 1: 1415588400000
Machine 2: 1415584800000
Without the hour/minute/seconds the result is the same.
Both machines are Windows 7 Professional but the Machine 2 have been recently updated from Windows Vista to Windows 7. Before the update, this command worked. Also, Machine 2 has only one installed update and Machine 1 has something like 200 updates installed.
Both machines have the same configuration about time and dates (formats, time Zone, etc)
What can cause the difference on Date.parse on two machines with same Time Zone?
EDIT: I'm from Argentina and both machines have Time Zone: (UTC-03:00) Buenos Aires

What can cause the difference on Date.parse
Time zones , user localization environment.
If you want to use dates (trustfully) either use :
Moment.JS
ISO format which is yyyy-mm-ddThh:mm:ss[+xy:zp]
Split it manually via / and create a new Date with each argument to its place.
As to your question :
Date.parse('2014-11-10T00:00:00Z')
Will work in all browsers with the same value. notice It's UTC.
But,(if you need) - just add time zone eg:
Date.parse('2014-11-10T00:00:00+03:00')
And if you want a date object out of it :
new Date(Date.parse('2014-11-10T00:00:00+03:00'))

This is a compound issue.
Argentina used to have daylight saving time, back in 2009. From 2010 forward, they no longer have it. Reference Here.
JavaScript has a known issue with not using the correct DST rule, but just the most current rule it knows about. Details Here.
The machine that is returning 1415584800000 is using UTC-2 instead of UTC-3 because it did not get the update which added the new rule for 2010 forward. It is still using 2009's rule, which would place this date into daylight saving time.
This updated was included in KB976098 - the December 2009 cumulative time zone update for Windows.
You can verify this by looking in the registry at the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Argentina Standard Time\Dynamic DST
With the update applied, it should look like this:
Without the update, it will not have the entry for 2010.
You should always apply time zone updates - either automatically from Windows Update, or by watching the anouncment list at microsoft.com/time.

javascript seems to be using time zones backwards with Firefox

I've run the following in the console on Firefox (version 21) and I'm getting results I don't expect.
new Date(1362891600000);
var date = new Date(1362891600000);
var time = date.getHours();
new Date(date.setHours(date.getHours() + 24));
The result really throws me for a loop.
The first date shows up as Eastern Daylight Time, while the second one shows up with Eastern Standard Time. It's totally backwards. This does not happen with IE or with Chrome.
What's going on here?

This is definitely a bug in Firefox. You should probably report it to them.
However, be aware that anything after the offset is non-standard and support varies wildly across browsers and operating systems.
For example, some browsers display a time zone name, while others display an abbreviation or internal id. Also, some keep their own strings, and some use the values returned by the operating system. And on Windows, there is a different time zone database than on Linux or Mac. Also, some browsers may localize this string using language, locale, or culture settings.
You can display it to a user, if you know the value is in their own local time zone. But don't rely on it for anything critical.