This question already has answers here:
Create a Date with a set timezone without using a string representation
(29 answers)
How to initialize a JavaScript Date to a particular time zone
(20 answers)
Closed 8 years ago.
I have a timezone string, for example, "Pacific Time (US & Canada)". I need to get the equivalent of 3pm in that timezone in UTC for particular dates, including daylight savings time. How can I go about this?
For example, I need to find 3pm on December 3rd, PDT in UTC time.
That time zone identifier looks like it came from Rails, or from Twitter (which uses Rails). You first need to convert it to a standard IANA zone identifer such as "America/Los_Angeles". See the MAPPING declaration in the ActiveSupport::TimeZone docs.
Then you can use one of the libraries I mentioned here.
In particular, you may want to try moment-timezone. You'll need the latest develop version for this particular feature, as it was added in issue #25 which is not yet in the current release. Then you can do something like this:
moment.tz("2013-12-03T15:00:00","America/Los_Angeles").utc().format()
You can adjust the input/output format to whatever makes sense for you and is supported by moment.js.
The other time zone libraries I mentioned may also offer similar features without as much overhead, so they are worth a look.
This seems to work for me though it does feel a little fragile
new Date('2013-12-03 15:00:00 PDT').toUTCString()
-> "Tue, 03 Dec 2013 22:00:00 GMT"
Related
This question already has answers here:
Why does Date.parse give incorrect results?
(11 answers)
Closed 5 years ago.
I have an Array with date strings formatted: "24-Jul-2017".
and when i use new Date("24-Jul-2017");
it returns date with one day offset.
2017-07-23T22:00:00.000Z
Tried different formatting but could not get correct date.
Assuming the browser is in a time zone with a UTC offset of +2 at the start of July 24th 2017, it's behaving as documented.
The Date constructor is documented as behaving like Date.parse, which then includes this documentation - along with multiple warnings not to use the constructor accepting a string, or the parse method:
Given a date string of "March 7, 2014", parse() assumes a local time zone, but given an ISO format such as "2014-03-07" it will assume a time zone of UTC (ES5 and ECMAScript 2015). Therefore Date objects produced using those strings may represent different moments in time depending on the version of ECMAScript supported unless the system is set with a local time zone of UTC. This means that two date strings that appear equivalent may result in two different values depending on the format of the string that is being converted.
So it's providing you July 24th 2017 at midnight in the local time zone.
It sounds to me like you'd be better off using Moment.js or something similar to give you clearer control over the parsing/formatting.
new Date(Date.UTC(year, month, day, hour, minute, second))
Try this format (UTC will be the timezone for your Date)
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 pick some date and time in javascript and then want to store it on server (.NET). Dates are supposed to be in future from the current moment (so they won't be before 1970).
Having read topics here on SO I learnt it's better to store date as a string and people suggest using Date.prototype.toISOString() or Date.prototype.toUTCString().
I've read that toISOString() is not available in IE 7. And I'd like to know other differences, when I should choose one or another function.
They're for different purposes.
UTC is the primary time standard by which the world regulates clocks and time.
ISO is standard format time. ISO also supports ms in its format.
So if you want to send data to the server, send the ISO, because ISO is the standard format:
var date = new Date();
sendDate(date.toISOString());
You can also use toISOString in IE7 polyfill.
I hope it will helpful to you.
Summary About toISOString() :-
The toISOString() method returns a string in ISO format (ISO 8601 Extended Format), which can be described as follows: YYYY-MM-DDTHH:mm:ss.sssZ. The timezone is always UTC as denoted by the suffix "Z".
Refer Below link for more information about toISOString().
Date.prototype.toISOString()
Summary About toUTCString() :-
The toUTCString() method converts a date to a string, using the UTC time zone.
Refer Below link for more information about toUTCString()
Date.prototype.toUTCString()
Always use .toISOString()
They give almost the same information, but in different formats. Here is what I get on my machine.
new Date().toISOString()
"2019-10-11T18:56:08.984Z"
new Date().toUTCString()
"Fri, 11 Oct 2019 18:56:08 GMT"
There are 4 reasons .toISOString() is more often what you want than .toUTCString().
A. More convenient sorting
When you sort alphabetically, the "2019-10-11T18:56:08.984Z" pattern of .toISOString() gives you the correct date order.
B. Millisecond precision
.toISOString() provides millisecond values, whereas .toUTCString() does not.
C. Any user can interpret correctly
The .toUTCString() value may be more familiar to human end-users, but only if the language settings are suitable for them. In contrast, the .toISOString() is the same regardless of language settings.
D. Reproducibly regeneratable by software
You can easily convert the ISO date string to a Javascript Date object, and then back again, regenerating exactly the same string. This is regardless of who gave you the ISO date string, where the server is, and where you are.
This is not automatically true for the UTC string. For example, if a second instance of your app system is running in a different time zone, or language, it's .toUTCstring() may use different numbers or words (respectively) to represent the same instant in time. It will be difficult for it to create a UTCString that matches what was made by the first instance of the app, since in general it will not know the language or timezone in which the first UTC string was produced.
I think nobody needs .toUTCString()
I don't know why `.toUTCString()` exists. Its word-heavy format makes it useless for internal storage of dates in your program, because it varies depending on your language and timezone setting etc.
So maybe it is to produce something nice to display externally for the user to see? Well, not really. Anyone who is not in the London time zone will not find it very helpful.
I live in London. And even I, even if I was writing an app purely for use by me, solely on my system, and only in my home, would still not want to use .toUTCString(). Because it is showing UTC (also known as GMT). London is not always on GMT. In summer, we move to GMT+1, so the .toUTCString() result would mislead anyone who didn't notice the "GMT" and do the time adjustment in their head.
If I wanted a natural-language time, to make non-computer literate users comfortable, I would construct it manually from parts, using a library like moment.js. If I wanted a quick-and-dirty solution, I would use .toString() which at least will move to Summer time when appropriate.
I have set a deadline in UTC, as shown below, and I'm wondering what exactly the toLocaleString() method will do to it on user's local machines. For instance, will it account for daylight savings if they are in a timezone that recognizes it? Or will I need to insert additional code that checks where the user is, and then fixes the displayed time?
http://javascript.about.com/library/bldst.htm
var deadline = new Date('5/1/2013 ' + "16:15" + ' UTC');
alert(deadline.toLocaleString());
In general, the answer is yes. JavaScript will represent the UTC value at the appropriate local time based on the time zone settings of the computer it is running on. This includes adjustment for DST. However, as others have pointed out, the details are implementation specific.
If you want a consistent output, I would use a library to format your dates instead of relying on the default implementation. The best library (IMHO) for this is moment.js. The live examples on their main page will give you an idea of what it can do.
UPDATE
If you are passing UTC values that you want converted to the correct local time, and that time falls into a period where the time zone rules are different than the current one - then the results will be invalid. This is crazy, but true - and by design in the ECMA spec. Read - JavaScript Time Zone is wrong for past Daylight Saving Time transition rules
We don't know what exactly the toLocaleString method does (§15.9.5.5):
This function returns a String value. The contents of the String are
implementation-dependent, but are intended to represent the Date in
the current time zone in a convenient, human-readable form that
corresponds to the conventions of the host environment’s current
locale.
But yes, most implementations will consider DST if it is active in the current local timezone. For your example I'm getting "Mittwoch, 1. Mai 2013 18:15:00" - CEST.
Will I need to insert additional code that checks where the user is, and then fixes the displayed time?
I think you can trust toLocaleString - the browser should respect the user's settings. If you want to do it manually, check out timezone.js.
As you use "UTC" the date itself will be UTC format, but the toLocaleString() takes client's locale into account, which means it'll return the date in string updated with all and every changes typical to client's regional and locale settings (DST, date/time format, etc).As JS documentation describes this: "The toLocaleString() method converts a Date object to a string, using locale settings.".If you want to avoid this, use the toUTCString() method instead.I'd also recommend reading the accepted solution for the question Javascript dates: what is the best way to deal with Daylight Savings Time? to avoid (at least, to try to avoid :) future issues related to JS, browsers and locales.Hope this helps!
"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.