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
Related
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...
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.
I'm having an issue with timezones, DST and Node.js. It doesn't identify correctly DST effects. My OS is Windows 8.1 and have the timezone value and DST well set. I tried these two methods:
1) Node's Date Object
I typed the following code in Node Prompt and received the answer in italic:
new Date()
Tue Sep 09 2014 18:42:36 GMT-0200 (Horário brasileiro de verão(Brazilian Daylight Savings Time))
However, the brazilian DST starts just in Oct 19th, we are not in DST right now. Therefore, the hour is shifted 1 hour from now.
2) node-time
I got node-time package from npm, to be able to change Timezone. In the code:
time = require('time');
dateFormat = require('dateformat');
now = time.Date();
console.log(dateFormat(now.setTimezone('America/Sao_Paulo').getTime(), "yyyy-mm-dd HH:MM:ss Z"))
and as a result, I got
2014-09-09 18:42:36 GMT-0200
Brazilian normal timezone is GMT-0300. Hour is also 1 hour shifted.
Am I doing something wrong? Is there a workaround?
The node-time package does not work on Windows. I couldn't even get it installed, so I'm not sure how you did. You should uninstall it.
If you need support for non-local time zones in Node (or in the browser), I recommend moment.js with the moment-timezone plugin.
Running new Date() on Windows with the time zone set for Brazil, I get the correct output.
The only thing that would explain your results is if the time zone registry settings were modified - but then you'd also see the wrong time in your system clock on your taskbar. So I'm sorry, but I cannot reproduce that part of it.
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.
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?