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.
Related
I am struggling in formatting js date in a proper format and not sure if I'm doing this right.
So here's my case:
I import data strongly dependent on hours included in objects. Sometimes I received date with GMT +1 format and sometimes with GMT +2. I have figured out it depends on daylight saving date format.
But the problem is now, when I try to work on this data and I look for object from december, function getDate() would return me the day before (as hours would be 23:00 GMT +1 NOT 00:00 GMT +2)
I am working on client's oracle database and use it in nodejs server supported by oracledb npm package.
I was wondering if there is any nice / smooth way of unifying these date format to the same one? Like to receive all dates only in one of GMT +1/+2 format?
Thanks for any advice
What you'd like to do here is adjust the time according to getTimezoneOffset() and then store it.
MDN
The time-zone offset is the difference, in minutes, from local time to
UTC.
var d = new Date();
console.log(d)//Time before adjusting the timezone
d.setMinutes(d.getTimezoneOffset());
console.log(d) //time adjusted to UTC
I am receiving a MySQL Timestamp in UTC and trying to covert it to the client's local timezone. However, When i do this I get the wrong time zone.
Ive formatted my DateTime String to be: var utcTime = 2014-05-15T13:00:00Z
However when after my conversion my dateObject is: Date {Thu May 15 2014 09:00:00 GMT-0400 (EDT)}. However, I want my Timezone to be GMT -0500 (EST).
I've searched online and saw there is a way to do this by appending "UTC" to a MYSQL formatted Timestamp.. However, this method does not work in all browsers.
If anyone has any insight on converting timezones i would appreciate it.
The D in EDT stands for Daylight and the S in EST stands for Standard. EDT should be used during Summer in the U.S. and EST in the Winter (list of countries here). Is it possible that GMT -4 (EDT) is actually the right local time? If it would be more towards winter it would switch automatically to GMT -5 (EST). The client timezone together with daylight savings is handled automatically by Javascript.
For example, the default string representation of a certain date in Javascript should correctly choose between Standard time and Daylight Savings time based on the date object itself and the machine timezone:
var date = new Date(millisSinceUnixEpoch);
alert(date.toDateString() + ' ' + date.toTimeString());
Note: there's room for a lot of assumption though. E.g. not sure exactly how your 'conversion to local timezone' code looks like
I've seen something similar to this. This MSDN article may explain it.
Handling daylight saving time using JavaScript
http://msdn.microsoft.com/en-us/library/ie/jj863688%28v=vs.85%29.aspx
In Windows Internet Explorer 9 and previous versions of Windows
Internet Explorer, dates are customized by applying the ECMAScript
specification's rules for storing daylight saving time adjusted times
internally. To improve accuracy, especially with dates in the past
(historical dates), Internet Explorer 10 relies on the system's rules
for storing daylight saving time adjusted times. This topic contains
the following sections:
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
I am trying to googling for passing in acceptable parameters for setting up cronJobs based on a users timeZone. Im using a cronJob module which can be found here.
https://github.com/ncb000gt/node-cron
The problem is I need to pass different timeZones but I can't seem to find the acceptable parameters and format for the different timezones. Can anyone point me in the right direction?
Try converting the time to a common timezone before registering it with node-cron.
Here's a conversion example from another question.
From How to use timezone offset in Nodejs? :
var time = require('time');
var a = new time.Date(1337324400000);
a.setTimezone('Europe/Amsterdam');
console.log(a.toString()); // Fri May 18 2012 09:00:00 GMT+0200 (CEST)
a.setTimezone('Europe/Kiev');
console.log(a.toString()); // Fri May 18 2012 10:00:00 GMT+0300 (EEST)
I found it. For anyone encountering a similar problem here is a reference list by time zone acceptable for node.js. I believe its standard OS time zone stuff.
http://home.tiscali.nl/~t876506/TZworld.html
"During the "energy crisis" years, Congress enacted earlier starting dates for daylight time. In 1974, daylight time began on 6 January and in 1975 it began on 23 February. After those two years the starting date reverted back to the last Sunday in April. "
(via http://aa.usno.navy.mil/faq/docs/daylight_time.php )
There appears to be a bug in the Javascript date object for these dates. If you convert 127627200000 milliseconds to a date, it should be Thu Jan 17 00:00:00 EDT 1974. This is correct on http://www.fileformat.info/tip/java/date2millis.htm, but incorrect on
http://www.esqsoft.com/javascript_examples/date-to-epoch.htm, which says it converts to Wed Jan 16 1974 23:00:00 GMT-0500 (Eastern Standard Time). If you create a new Date(127627200000) object in javascript, it gives the latter date conversion. This happens in all major browsers.
I can't imagine this is first time this has been a problem for anyone, but I can't find any other cases of this problem with a few searches online. Does anyone know if there is an existing fix for this or an easier fix than manually checking the dates Javascript has the conversion wrong? Are there other dates this is a problem?
As ever, it's best to check the spec :)
In this case, I was pretty shocked to see this in section 15.9.1.9 of ECMA-262:
The implementation of ECMAScript
should not try to determine whether
the exact time was subject to daylight
saving time, but just whether daylight
saving time would have been in effect
if the current daylight saving time
algorithm had been used at the time.
This avoids complications such as
taking into account the years that the
locale observed daylight saving time
year round.
In other words, a conformant ECMAScript implementation is not allowed to be historically accurate.
Now whether all implementations follow this or not, I'm not sure... but it does suggest you'd need some kind of separate library if you wanted to get historically accurate time zones... where "historically accurate" doesn't have to be nearly as far back as 1974, of course: the US changed its DST schedule in 2007, and other countries have done so more recently than that (and with less warning).
1 The first occurrence of 15.9.1.9. For some reason it occurs twice - once for "Daylight Saving Time Adjustment" and once for "Local Time". Wow.
Java does historical time zones (back to about 1920), JavaScript apparently does not.