Javascript Date Gives me EDT but I want EST - javascript

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:

Related

getDate() giving wrong date due to Daylight saving timezone

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

Weird Javascript Timezones with Date()

Javascript hopeless here but I've got a problem I can't seem to understand, and don't know whether it's defined behavior in JS or not...
From what I can understand, new Date() returns the current time in the current timezone as reported by the browser. At the current time of writing this, I am in Milan, Italy (GMT +0200 CEST), so when performing the below:
var date = new Date();
console.log(date);
console.log(date.getTimezoneOffset());
I get, as expected:
Sun Oct 07 2018 15:42:12 GMT+0200 (Central European Summer Time)
-120
However, again from what I understand, throwing milliseconds into the Date Constructor creates a date based off of Epoch Time, 1st January 1970 00:00:00 GMT +0000 - So why if I perform:
var date = new Date(0); // Note The 0
console.log(date);
console.log(date.getTimezoneOffset())
Do I get:
Thu Jan 01 1970 01:00:00 GMT+0100 (Central European Standard Time)
-60
Did the browser for some reason change the timezone it thinks I am in? This is causing quite a few problems for me retrieving a unix timestamp from a database, and displaying it in the user's current timezone!
Any help or advice on this would be much appreciated!
Many thanks! :)
The numeric timestamp value inside every Date instance, no matter how it is constructed, represents an offset from a fixed UTC "epoch" time. When you construct a date in your locale, the timezone offset is taken into account when the Date instance timstamp is set. The timezone offset is also taken into account when you access parts of the date via locale-relative APIs like .getTimezoneOffset().
Thus what matters is how you get date/time information out of the Date instance. If you use UTC APIs, you get UTC time information. If you use locale-relative APIs, you get locale-relative values.
let d = new Date();
console.log("locale-relative: " + d);
console.log("UTC: " + d.toUTCString());
Now, as to how you handle the system timestamp values you've got in your database, that depends on how your application works and what the dates mean in that context. If it's important that users see the dates in terms of what your server(s) will do with them, format the dates on the server with locale-relative APIs. That would make sense if your application does some work based on local time. For example some banking applications (in the US) do things at night, but "night" in terms of late evening hours in the continental US.
If, on the other hand, the dates you store should be shown to your users in terms of their locales, then send the client the timestamp and format your dates as strings at the client with locale-relative APIs. That would be appropriate for an application that allows users to set up alarms etc: generally it makes sense for the user to think in terms of their own local time.

javascript create date without daylight savings conversion

when i create date using date constructor new Date('2015','12'), it results in Fri Jan 01 2016 00:00:00 GMT-0500 (Eastern Standard Time). But don't it to assume that what date i am providing is already applied daylight conversion and create date object for december 2015, instead of jan 2016
When creating a date using the Date constructor, the time zone of the host system is almost always used (per ECMA-262). The only exception is when a number (interpreted as a time value, i.e. milliseconds since the ECMAScript epoch) is provided, or an ISO 8601 format string with a time zone. Even then, the internal time value of the Date (i.e. milliseconds since the epoch) is calculated in UTC and the host system time zone offset used for the non–UTC methods like getHours, getMinutes, etc.
Also, the timezone offset of the current systems settings are used for historical dates. So if the host is set for daylight saving, it will be applied to dates at times before daylight saving was implemented. Also, historical changes to daylight saving changeover dates and times (and even value) are not applied. The currents settings are assumed to always apply for past and future dates.
So all of the following will apply the timezone offset of the host system when creating a date for 3 February, 2016:
new Date('2/3/2016'); // US format is assumed by most browsers.
// May also create an invalid Date
new Date(2016, 1, 3); // months are zero indexed so 1 is February
new Date('2016-02-03T00:00:00'); // note missing time zone
However, the following will be treated as UTC (or invalid):
new Date('2016-02-03'); // contrary to ISO 8601, missing time zone for this
// format only is assumed to be UTC
new Date('2016-02-03T00:00:00Z'); // Note has a time zone of GMT
If you want to reliably create a Date for a specific instant in time from a string, you must provide a string with the time zone offset. Then parse it yourself since parsing of date strings is largely implementation dependent and varies across implementations. The best format to use is ISO 8601 extended so something like:
'2016-02-03T00:00:00-0800'
which represents the same instant in time no matter what the settings of the host system are. You just need to reliably parse it.
There are many good libraries for parsing and formatting, or you can write your own small functions for particular parse and output formats.

Consistent Client Side Date/timestamp using JavaScript(considering TimeZones)

My question is regarding this quote from the manual about dates in JavaScript:
Note: parsing of date strings with the Date constructor (and
Date.parse, they are equivalent) is strongly discouraged due to
browser differences and inconsistencies.
new Date('2016-04-14') output for a user was Wed Apr 13 2016 17:00:00 GMT-0700 (US Mountain Standard Time) upon which he had to use .toUTCString().
How to handle this if the users are in many different time zones?
new Date().getTime(); returns an integer value as the time on client's machine since 1970 Jan 1.
Since this is an integer value, it will be agnostic of locales, browser version, different browsers (IE, Chrome, Mozilla, or anything).
So, this should give you consistent results in terms of time on client's machine as long as client's timezone is known.
You can fetch client's timezone offset by using getTimezoneOffset API
var x = new Date();
var currentTimeZoneOffsetInHours = x.getTimezoneOffset() / 60;
This together with new Date().getTime(); should give you consistent results.
If you use
new Date().getTime();
it will return you a milisecond time stamp since 1970-01-01 for the current time zone that the client is in. This can then be converted back to a date in any language.
This would be a better standard way to pass the date around if you are sending it to and from servers and between clients. As millisecond timestamp ts converted in timezone a will convert to 01/01/2010 and in timezone b will convert to 01/01/2010 as they are taken from 1970-01-01
Hope this makes sence

Daylight Saving Time in Javascript for 1974?

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

Categories