This question already has answers here:
Why does Date.parse give incorrect results?
(11 answers)
Closed 4 years ago.
What I am trying to do is changing "yyyy-mm-dd HH:mm:ss" string to date value.
Here is the current code
var c = new Date('2019-01-19 23:59:59'.replace(/\s+/g, 'T'))
It returns
chrome : Sat Jan 19 2019 23:59:59 GMT+0900 (KST)
safari : Sun Jan 20 2019 08:59:59 GMT+0900 (KST)
ie11 : Sat Jan 19 2019 23:59:59 GMT+0900 (KST)
What should I do to make it returns all same date?
Thanks.
Safari... It does not consider time zone offset when creates an instance with date string.
Add Z to the end is also good point, but if you want to get the same result with other browsers, should calculate timezone offset.
Here is what I have done ...
// Before do this, check navigator.userAgent
// and execute below logic if it is desktop Safari.
// Add Z is the convention, but you won't get any error even if do not add.
var c = new Date('2019-01-19 23:59:59Z'.replace(/\s+/g, 'T'))
// It will returns in minute
var timeOffset = new Date().getTimezoneOffset();
// Do not forget getTime, if not, you will get Invalid date
var d = new Date(c.getTime() + (timeOffset*60*1000))
Will open this post till tomorrow for waiting better answer.
Thanks.
Add the 'Z' to the date string for GMT/UTC timezone
var c = new Date('2019-01-19 23:59:59'.replace(/\s+/g, 'T')+'Z');
ISO dates can be written with added hours, minutes, and seconds (YYYY-MM-DDTHH:MM:SSZ):
Date and time is separated with a capital T.
UTC time is defined with a capital letter Z.
If you want to modify the time relative to UTC, remove the Z and add +HH:MM or -HH:MM instead:
for example
var d = new Date("2019-01-19T23:59:59-09:00");
Related
I understand that dealing with dates, in any environment, could be quite confusing, but I'm in a nightmare with a function that should be a trivial job.
I want to manipulate in different ways some dates, but I get errors or wrong results.
I report hereafter a very simple example made to test the execution; the goal here is to get the current month beginning date, just to show what happens:
function DateAdjust() {
var newdate = new Date(); //1: 2018-12-12T21:00:20.099Z
newdate = newdate.setDate(1); //2: 1543698020099
newdate=Date(newdate); //3: Wed Dec 12 2018 21:01:43 GMT+0000 (Ora standard dell’Europa occidentale)
var d = newdate.getDate(); //4: newdate.getDate is not a function
}
4 lines, 3 unexpected results (as shown by Firefox's debugger):
1. the starting date has no day-of-week and no timezone
2. setting the day, result is transformed in milliseconds (why?); I do not know if it is correct.
3. reconverting in string gives the original date, unmodified (why?) but with week day and timezone
4. trying to get the day value an error is thrown (why?)
My environment:
Win 7 32bits SP1
Firefox 63.0.3 (32 bit)
jquery-2.2.4.min.js
I know these questions are boring, but hope someone will find few minutes to clear my mind.
Regarding line 1, the Z at the end is the timezone designation for UTC in ISO 8601 (see Wikipedia).
If the time is in UTC, add a Z directly after the time without a space. Z is the zone designator for the zero UTC offset. "09:30 UTC" is therefore represented as "09:30Z" or "0930Z". "14:45:15 UTC" would be "14:45:15Z" or "144515Z".
Regarding line 2 see the MDN article on setDate (emphasis mine):
The number of milliseconds between 1 January 1970 00:00:00 UTC and the given date (the Date object is also changed in place).
So you can see the 'correct' behavior you probably expect simply by ignoring the return value:
var newdate = new Date(); //1: 2018-12-12T21:00:20.099Z
newdate.setDate(1); //2: 1543698020099
console.log(newdate); //3: 2018-12-01T21:00:20.099Z
Regarding line 3, see MDN article on Date (emphasis mine):
Note: JavaScript Date objects can only be instantiated by calling
JavaScript Date as a constructor: calling it as a regular function
(i.e. without the new operator) will return a string rather than a
Date object; unlike other JavaScript object types, JavaScript Date
objects have no literal syntax.
Regarding line 4, the above also explains this error, since newdate is now a string rather than a Date object.
For what it's worth, I agree with the other commenters. JavaScript's date functions are pretty messy compared to many other modern languages. I strongly recommend using a library like moment, luxon, or date-fns. It'll make your life much easier.
I do recommend using moment.js
But there are 2 problems with your code:
1-
newdate = newdate.setDate(1);
setDate mutates newDate in place, and return it in miliseconds, not a new Date object. If you just want to set the date, do this instead:
newdate.setDate(1);
2-
newdate=Date(newdate);
Not realy sure why you are trying to get a new Date object, but you need the new, otherwise it will just be a string
newdate= new Date(newdate);
Fixing problem 1 should eliminate the need for the code of problem 2
var newdate = new Date(); // 1
console.log(typeof newdate, newdate); // object Wed Dec 12 2018 23:00:44 GMT+0200 (Eastern European Standard Time)
newdate = newdate.setDate(1); // 2
console.log(typeof newdate, newdate); //number 1543698085383
newdate=Date(newdate); //3
console.log(typeof newdate, newdate); //string Wed Dec 12 2018 23:04:44 GMT+0200 (Eastern European Standard Time)
var d = newdate.getDate(); // 4
console.log(typeof d, d); //
Date type is assigned to the object.
number is assigned to newdate. which is ticks
returns string
string.getDate() is not defined, so undefined.
hope it helps.
When I try to parse a string date from March, new Date() works incorrectly. But when my string date is from April, everything is fine. I don't understand this. Why does it work like that?
var a = '2018-03-07T00:00+03:00';
console.log(a);
console.log(new Date(a).toString());
var b = '2018-04-07T00:00+03:00';
console.log(b);
console.log(new Date(b).toString());
Here's a screenshot from Google Chrome browser:
As others pointed out, it's due to the daylight saving time in your time-zone. Notice the times in your screenshot: the time for a is 23 and for b is midnight 00, which clearly tells you what happened.
If you want to parse the values without the daylight saving time, you can use the GMT+0 time-zone by replacing your time-zone +3:00 with z. However, then you need to correct time manually by adding/subtracting the hours of your time-zone (-3 in your case). Here is an example:
var a = '2018-03-07T00:00+03:00';
a.replace('+03:00', 'z');
a = new Date(a);
a.setHours(a.getHours() - 3); //3 is your time-zone
console.log(a.toUTCString());
var b = '2018-04-07T00:00+03:00';
b.replace('+03:00', 'z');
b = new Date(b);
b.setHours(b.getHours() - 3); //3 is your time-zone
console.log(b.toUTCString());
Obviously, this code will only work for one known time-zone. If your values can be in different time-zone, then instead of replacing, you need to extract the time-zone from the string (the last 6 characters in this format, except for GMT-0 which is z), and then use it to correct the time on the setHours() line.
Because of summer daylight saving time. According to Date documentation, the date is specific moment in time relative to Jan 1st 1970. That moment in time in March belonged to the part of year with daylight saving offset in your specific locale
Your first date is Standard Time... and the second one is Daylight Time.
var x = new Date('2018-03-07T00:00+03:00');
console.log(x);
var y = new Date('2018-04-07T00:00+03:00');
console.log(y);
In your scenario... EET – Eastern European Time versus EEST – Eastern European Summer Time like shown on console.
Why cannot IE parse this string as a Date object.
var d = Date.parse("Fri Jun 11 04:55:12 +0000 2010"); // returns NaN
However, it works well in FireFox. I am running IE 8.
Thanks.
You are getting NaN value in IE 8 and its working in Firefox because the format of the string varies with browser and operating system.
For example, in IE6 for Windows XP, the string is in the following format:
Tue Dec 05 16:47:20 CDT 2006
But in Firefox for Windows XP, the string is
Tue Dec 05 2006 16:47:20 GMT-0500
to make it compatible with both browser you will have to first check the browser in your
javascript code and then accordingly give your input date string.
I've found the jQuery Globalization Plugin date parsing to work best. Other methods had cross-browser issues and stuff like date.js had not been updated in quite a while.
You also don't need a datePicker on the page. You can just call something similar to the example given in the docs:
$.datepicker.parseDate('yy-mm-dd', '2007-01-26');
Is solved my problem by creating an date object and let me give it back the timestamp.
But for this you need to convert you string into this format:
year, month, date, hours, minutes, seconds,ms
an example would be like:
dateObj = new Date(year, month, date);
timestamp = dateObj.getTime();
This works save in IE and FF.
IE Dev Center: Date Object (JavaScript)
Mozilla Dev Network: Date
For your example you would to something like this:
//your string
var str = "Fri Jun 11 04:55:12 +0000 2010";
//maps months to integer from 0 to 11
var monthArray = {"Jan":0, "Feb":1, "Mar":2, "Apr":3, "May":4, "Jun":5, "Jul":6, "Aug":7, "Sep":8, "Oct":9, "Nev":10, "Dec":11};
//get the values from the string
var regex = /^[^ ]+ ([^ ]+) (\d{1,2}) (\d{2}):(\d{2}):(\d{2}) \+(\d{4}) (\d{4})$/;
match = regex.exec(str);
var month = monthArray[match[1]],
date = match[2],
hours = match[3],
minutes = match[4],
seconds = match[5],
ms = match[6],
year = match[7];
//create date object with values
var dateObject = new Date(year, month, date, hours, minutes , seconds, ms);
var ts = dateObject.getTime(); //timestamp in ms
Problem
In case your date is stored in SQL datetime like 2020-04-07 05:30:00 and want to parse it in IE. When you parse it with JavaScript in IE using new Date(), it outputs Invalid Date while latest versions of Chrome and Firefox parse this date correctly.
Solution
You have to replace <space> with T in datetime string coming from SQL.
Example
let myDate = '2020-04-07 05:30:00';
let myFormattedDate = myDate.replace(' ', 'T'); // '2020-04-07T05:30:00'
console.log(new Date(myFormattedDate));
because of the +00000. try to add that the last
var d = Date.parse("Fri Jun 11 04:55:12 2010 +0000");
This may help you. I just solved a problem similar to this.
Problem with Javascript Date function in IE 7, returns NaN
This question already has answers here:
Is the Javascript date object always one day off?
(29 answers)
Closed 6 years ago.
var dateTest = new Date('2015-03-31');
console.log(dateTest);
Result:
Mon Mar 30 2015 20:00:00 GMT-0400 (Eastern Daylight Time)
However I expected this to be March 31. How might I do this?
Because it's setting the date according to UTC, and returning it with your local timezone offset. I'd recommend explicitly specifying the timezone offset, if that's what you need, or adding your timezone offset after the fact.
var d = new Date('2015-03-31T00:00:00-0400');
// or
var d = new Date('2015-03-31');
d.setMinutes(d.getMinutes() + d.getTimezoneOffset());
If you want it to be in UTC, you can call the toUTCString() method on it instead, which will give you the date you expect, albeit not in your timezone.
I'm creating dates like this:
var StartDate = new Date(data.feed.entry[i].gd$when[j].startTime);
When a date string is received specifying date and time in the form:
"2014-04-12T20:00:00.000-05:00"
Date() interprets this perfectly fine returning:
Sat Apr 12 2014 19:00:00 GMT-0500 (CDT)
However, when the date string is received with no time information in the form:
"2014-04-07"
then Date() is interpreting it as:
Sat Apr 05 2014 19:00:00 GMT-0500 (CDT)
Looks like Date() is taking the -07 as the time and I have no clue where is it getting the date as 05. Any idea what might be the problem?
Could it be, somehow, Date() is interpreting a different time zone because in the first string the time zone is determined at the very end but in the "all day" event there is no indication of the time zone.
Has anybody found this issue? If yes, how did you solve it?
UPDATE: After researching a little bit more this parsing issue I noticed something very weird:
The following statement:
new Date("2014-4-07")
would return Mon Apr 07 2014 00:00:00 GMT-0500 (CDT) which is correct, but the following one:
new Date("2014-04-07")
returns Sun Apr 06 2014 19:00:00 GMT-0500 (CDT) which is the wrong one. So, for whatever reason, seems like the padding zeros affect the way the date is parsed!
You're using the Date() function wrong.
It only accepts parameters in the following formats.
//No parameters
var today = new Date();
//Date and time, no time-zone
var birthday = new Date("December 17, 1995 03:24:00");
//Date and time, no time-zone
var birthday = new Date("1995-12-17T03:24:00");
//Only date as integer values
var birthday = new Date(1995,11,17);
//Date and time as integer values, no time-zone
var birthday = new Date(1995,11,17,3,24,0);
Source: MDN.
The Date() function does not accept timezone as a parameter. The reason why you think the time-zone parameter works is because its showing the same time-zone that you entered, but that's because you're in the same time-zone.
The reason why you get Sat Apr 05 2014 19:00:00 GMT-0500 (CDT) as your output for Date("2014-04-07" ) is simply because you used it in a different way.
new Date(parameters) will give the output according to the parameters passed in it.
Date(parameters) will give the output as the current date and time no matter what parameter you pass in it.
Prior to ES5, parsing of date strings was entirely implementation dependent. ES5 specifies a version of ISO 8601 that is supported by may browsers, but not all. The specified format only supports the Z timezone (UTC) and assumes UTC if the timezone is missing. Support where the timezone is missing is inconsistent, some implementations will treat the string as UTC and some as local.
To be certain, you should parse the string yourself, e.g.
/* Parse an ISO string with or without an offset
** e.g. '2014-04-02T20:00:00-0600'
** '2014-04-02T20:00:00Z'
**
** Allows decimal seconds if supplied
** e.g. '2014-04-02T20:00:00.123-0600'
**
** If no offset is supplied (or it's Z), treat as UTC (per ECMA-262)
**
** If date only, e.g. '2014-04-02', treat as UTC date (per ECMA-262)
*/
function parseISOString(s) {
var t = s.split(/\D+/g);
var hasOffset = /\d{2}[-+]\d{4}$/.test(s);
// Whether decimal seconds are present changes the offset field and ms value
var hasDecimalSeconds = /T\d{2}:\d{2}:\d{2}\.\d+/i.test(s);
var offset = hasDecimalSeconds? t[7] : t[6];
var ms = hasDecimalSeconds? t[6] : 0;
var offMin, offSign, min;
// If there's an offset, apply it to minutes to get a UTC time value
if (hasOffset) {
offMin = 60 * offset / 100 + offset % 100;
offSign = /-\d{4}$/.test(s)? -1 : 1;
}
min = hasOffset? +t[4] - offMin * offSign : (t[4] || 0);
// Return a date object based on UTC values
return new Date(Date.UTC(t[0], --t[1], t[2], t[3]||0, min, t[5]||0, ms));
}
An ISO 8601 date string should be treated as UTC (per ECMA-262), so if you are UTC-0500, then:
new Date('2014-04-07'); // 2014-04-06T19:00:00-0500
The behaviour described in the OP shows the host is not compliant with ECMA-262. Further encouragement to parse the string yourself. If you want the date to be treated as local, then:
// Expect string in ISO 8601 format
// Offset is ignored, Date is created as local time
function parseLocalISODate(s) {
s = s.split(/\D+/g);
return new Date(s[0], --s[1], s[2],0,0,0,0);
}
In your function you can do something like:
var ds = data.feed.entry[i].gd$when[j].startTime;
var startDate = ds.length == 10? parseLocalISODate(ds) : parseISOString(ds);
Also note that variables starting with a capital letter are, by convention, reserved for constructors, hence startDate, not StartDate.
(I would add a comment but i don't have 50 rep yet)
See what
new Date().getTimezoneOffset()
returns, I would expect a big negative value, that would be the only reasonable explanation to your problem.
I have had some trouble with date conversions in the past, in particular with daytime saving timezones, and as work around i always set the time explicitly to midday (12:00am). Since I think you were using knockout, you could just make a computed observable that appends a "T20:00:00.000-05:00" or the appropiate time zone to all "day only" dates