We Keep Coding

new Date() not returning region

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...

Both Chrome and Node use V8, but give different result? [duplicate]

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.

JavaScript Date object Windows vs Ubuntu

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.

Timezone and DST problems on the latest 2014 Samsung Smart TV firmware

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

Confusion over noon versus midnight with date.js

I am using date.js in my project, and I am encountering something I didn't expect with respect to dates that had time components of exactly noon or exactly midnight.
When I use the native javascript Date.parse method, I get the result I expected when parsing a date:
// plain old javascript
var date = new Date(Date.parse("10/21/2010 12:00:00 PM"));
alert(date);
I get this:
Thu Oct 21 2010 12:00:00 GMT-0500 (Central Daylight Time)
I interpret this as noon on October 21, 2010, which is what I think my input date is. However, when I import date.js and try something similar,
// using date.js
var date = Date.parseExact("10/21/2010 12:00:00 PM", "M/d/yyyy hh:mm:ss tt");
alert(date);
I get this:
Fri Oct 22 2010 00:00:00 GMT-0500 (Central Daylight Time)
This looks to me like midnight on the following day. I have no idea why it's interpreting this as midnight, or at any rate why it's interpreting this differently than the default Date.parse in javascript. Am I confused over the meaning of 12:00 PM? Am I misusing date.js's parseExact?

Looks like a version issue:
http://jsfiddle.net/4QK8Q/
http://jsfiddle.net/JKg3n/
The first one is your file (from the google code base), the second is from their website (datejs.com). Funnily enough they look like the same version, but obviously aren't. I'm not familiar enough with the library to tell what's going on, but I suggest filing a bug report.

This is a fairly old question, but for those who may stumble upon this in a search, it's highly suggested that you switch to the currently maintained version of Date.js (https://github.com/abritinthebay/datejs/) if you're encountering unexpected behavior.
The versions on the Google code base and datejs.com both have unfixed bugs that are unlikely to ever be addressed, as the original developer seems to have abandoned the project.