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.
Related
Take the date '2022-04-01' and another date '2022-05-15' for example. When I calculated their deviation in Chrome devtools, what I got is:
The result is 3801600000. But when my friend did the same thing in another device, what he got is:
The result is 3798000000. The difference between 3801600000 and 3798000000 is exactly one hour. What may causes this result? How can I eliminate this difference?
You lack the zone data:
UTC datetime: new Date("2021-01-01T12:00:00Z");
UTC-4 datetime: new Date("2021-01-01T12:00:00-04:00");
The main issue you are experiencing is because your input string is being interpreted as assigned to the local time zone, and you have different time zones on the two machines you've been testing with. One of them has a DST transition between the two dates, and the other does not - which explains your one hour difference.
The examples you show also reveal your possible time zones:
Your machine is showing 8 hours ahead of UTC (UTC+8) for both timestamps. There are several parts of the world that use UTC+8 without DST, including China, Western Australia, Irkutsk Russia, and many others. There are no places on earth that use UTC+8 in conjunction with DST.
Your friend's machine is a different story. The timestamps are showing 2 hours ahead of UTC (UTC+2) on 2022-04-01, and 3 hours ahead of UTC (UTC+3) on 2022-05-15. While many countries use those offsets (such as those that are in Eastern Europe that use EET/EEST), none of those areas have a DST transition between those two dates. See the bottom of this table of DST transitions. All of the +2/+3 areas of the world transitioned in March. I can only conclude that your friend's machine has some non-standard time zone setting, or they are significantly behind on time zone data updates, or both. (Please reply in comments if I am incorrect on this!)
Also, your input string format, 2022-04-01 00:00:00 is not in the standard date time string format defined by the ECMAScript specification. Thus, it is not guaranteed to be parsed consistently by all browsers. Current versions of Chrome, Edge, and Firefox will interpret it as a local date and time, but the current version of Safari will fail with "Invalid Date".
If you want it interpreted as local time correctly in all browsers, you would need to specify it as 2044-04-01T00:00:00.
If you want it interpreted as UTC then specify as 2044-04-01T00:00:00Z.
If you want it interpreted with a specific time zone offset, then append that instead, as in: 2044-04-01T00:00:00+08:00.
If you must parse the string in the original format, then don't do it using the Date object. Either use a library (such as Luxon or date-fns), or parse it yourself with regex and/or string manipulation techniques.
Since today I noticed a problem in one of the webapps running on my server, in that it reported the timezone wrong - but only on Firefox
And indeed, checking in the console:
Intl.DateTimeFormat().resolvedOptions().timeZone
delivers
Etc/GMT-1
What's this supposed to mean? I am in a GMT+1 (+2 when counting currently active daylight savings time) timezone.
On Chrome, the above command correctly returns Europe/Vienna.
OS: Windows 10, Firefox version: 59.0.2 (64 bit) with Add-Ons: NoScript, PrivacyBadger, uBlock Origin (tried with add-ons deactivated, no change), Chrome 65.0.3325.181 (64-Bit)
Is this a Firefox bug (though as far as I can tell Firefox was not updated in the past few days, and the problem only started today)?
In the webapp also nothing changed as far as I can tell, so I suspect this to be a Firefox issue somehow (though I have no idea how Firefox gets to this "wrong" timezone info). Or is the timezone actually correctly referencing a time 2 hours ahead of UTC? And is the webapp mabye wrong in not recognizing this properly? I'm fresh out of ideas.
Searching in google hasn't brought up any recent hints regarding this (only some outdated ones, e.g.: Incorrect timezone in Firefox, compared to Safari, using javascript Date(), https://support.mozilla.org/de/questions/1191823). I also can't find anything else pointing at unusual timezone readings currently in Firefox, so I'm really wondering where this is coming from!
UPDATE:
To be honest, I have no idea what timezone firefox reported before - the actual problem I have is that the webapp (owncloud), when run in Firefox, reports not knowing the time zone specification - the message translates to "unknown timezone specification Etc/GMT-1. Falling back to UTC". The times are then 2 hours behind what I would expect them to be (which makes sense as current europe/vienna or europe/berlin time is 2 hours ahead of UTC). Not knowing how to interpret Etc/GMT-1 might be an issue on owncloud's part, but it has worked up until a few days ago, and still continues to work on Chrome...
More info as requested by Matt Johnson below:
>tzutil /g
W. Europe Standard Time
>echo %TZ%
%TZ%
Registry:
I suppose I get Europe/Vienna instead of Europe/Berlin since I have configured to be located in Austria?
Addendum: I only get this behavior so far only on a single Windows 10 machine. On another Linux machine running Firefox, I do not see this behavior. I yet have to check on another Windows 10 machine
There are two separate questions here:
Etc/GMT-1
What's this supposed to mean? I am in a GMT+1 ...
The tz database identifiers of the form Etc/GMT±* deliberately have an inverted sign than the usual forms we expect under ISO 8601. That is, they are in terms of positive values being West of GMT, rather than positive values being East of GMT. This is covered both in the Wikipedia article on the tz database, and in the commentary in the tz database itself.
Thus, it does indeed align with the current GMT+1 offset of your time zone. However, it doesn't reflect any DST of GMT+2.
... On Chrome, the above command correctly returns Europe/Vienna.
... Is this a Firefox bug?
That depends. What is your OS time zone set to? You said you are running Windows 10. Though Europe/Vienna maps to W. Europe Standard Time, the primary (001) mapping for that would be Europe/Berlin - so it's a bit odd that you would get Europe/Vienna unless there is something else influencing the result.
It is possible you have stumbled upon a bug, but it's also possible you have customized or corrupted time zone settings on your OS.
Please supply (via edit of your question) the values of:
The output of the tzutil /g command on the command line.
The value (if any) of a TZ environment variable (echo %TZ%)
All the values under this registry key (screenshot would be best):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
That will help identify the problem further. I will edit my answer accordingly. Thanks.
This is the strangest behavior I have witnessed in JavaScript.
Under a very specific set of circumstances, this code will yield a time that's 40 minutes and 28 seconds earlier:
var jsDate = new Date('01/01/1900 11:00:00');
jsDate.setSeconds(0);
var dateString = jsDate.toLocaleTimeString("en", {
hour12 : false
});
alert(dateString); //dateString will be 10:19:32
This happens for one site in the Netherlands but not for our developer there. It happens on Firefox and Chrome. The workstation is Windows 7.
Testing it, I found that the broken result happens for any year prior to 1942.
For 1943 and 1944, it adds an hour.
Every year after that works fine, regardless of the date format: 01/01/1900 and 1900-01-01.
Background for the curious:
We have a date time widget and are only interested in the time portion.
The fix is to set the dummy date to 2000. But we are boggled about the "why".
Link to jsFiddle
This issue is not related to UTC vs Localized time. The strangest feature is that it alters the time by minutes and seconds, not hours.
I'll stick to your Netherlands example that was returning 10:19:32, and address the why part of this question.
The time zone database entry for Europe/Amsterdam is here, and looks like this:
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Europe/Amsterdam 0:19:32 - LMT 1835
0:19:32 Neth %s 1937 Jul 1
0:20 Neth +0020/+0120 1940 May 16 0:00
1:00 C-Eur CE%sT 1945 Apr 2 2:00
1:00 Neth CE%sT 1977
1:00 EU CE%sT
Since you passed a date in 1900, the second line applies, which has an offset from UTC of 0:19:32, which happens to coincide with the Local Mean Time (LMT) entry above it.
As Chris Pearce explains in The Great Daylight Saving Time Controversy:
... All this was in a country that hadn't yet adopted standard time. Controversy had raged in the Netherlands over whether it should use GMT and turn clocks back about 20 minutes or use GMT+1 and go forward 40 minutes. Agreement couldn't be reached, so they stayed on local time long after all other European countries had moved to standard time. Local mean time of capital city Amsterdam, GMT+0:19:32, had been used nationwide for decades and this became the legal time ...
With regard to other time zones, you're likely hitting on their own interesting bits of history, or just on the Local Mean Time entry in the TZDB, which is usually the earliest entry and is used when there is no other history known about timekeeping in the region.
The lesson here is that time zones are a relatively modern invention, and have often been a point of political controversy. Don't assume that because you know how they work today that your knowledge will apply to the past. Keep in mind also that as various tidbits of history are uncovered, the TZDB is updated accordingly, so indeed history can change!
In general, expect to encounter oddities for any dates before 1970.
As to why you don't get this same result in every browser, see my oldish blog post JavaScript Date type is horribly broken, which among other things describes that ECMAScript 5.1 and prior required TZ/DST rules to ignore the history of timekeeping and assume the current rule always existed. This was fixed in ECMAScript 6, and in the ECMA Internationalization API - so most modern browsers will give you the correct result.
However, it also depends on where they source their time zone data. Windows computers don't have the full history of the tzdb, unless the browser ships their own copy of it. Browsers that use ICU for this functionality do ship their own copy of the TZDB, so those would have the historical data, but not every browser does this.
Have a site for training webex events. Our company is located in several different timezones. In the past everything has been converted to Pacific time (where we are headquartered). Trying to focus more on user experience and make things more local and less about HQ.
So all the times are shown in local time, but this is now confusing users because they don't expect it. I'd like to add three letter initials (PST, CMT, EST, HAST or HST, etc.)
As I'm looking into this I'm keep getting referred back to moment timezone. We are already using moment for other date/time stuff, so that would be awesome.
But all the timezone examples are like this:
moment.tz([2012, 0], 'America/New_York').format('z'); // EST
Basically it seems like you already need to know what timezone the user is in. If I already knew what timezone they were in I wouldn't need moment to tell me. Also the documentation says:
...By default, moment objects are created in the local time zone....
I'm located in Portland, Oregon, javascript new Date() shows (PST) (in Chrome at least), but moment.tz().zoneAbbr() is UTC, so clearly not my local time zone.
I found this thread that recommends using jsTimezoneDetect.
moment.tz(new Date(), jstz.determine().name()).format('z')
I understand why this is a complex thing given locations around the world and different daylight savings schemes. But I have to wonder -- am I missing something? Is there some easier way to do this?
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.