new Date() not returning region - javascript

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

Related

toLocaleString incorrect in Firefox for AEDT

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.

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.

Different Date.ToString (IE 8 local site vs google)

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 )

javascript - Date() not accounting for Daylight Savings in website script, but does when executed in Firefox console

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.

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

Categories