Develop Reference

Wrong unix time from parsed DateTime

Here is code
const dateStr = '1989-11-11T03:34';
let date = new Date(dateStr);
console.log(date.toUTCString());
console.log(+date);
And output:
Fri, 10 Nov 1989 22:34:00 GMT
626740440000 <--- far future
Why unix time is in far future?
Here is Playcode link

It's not wrong.
You seem to have two issues with what you're getting:
The time isn't the same in your toISOString output.
The number you're getting from +date isn't what you expect.
But both are correct:
The string has no timezone indicator on it, so since it's a date+time string, it's parsed as local time. This is covered by the Date Time String Format section of the specification. But your output is showing GMT (because toISOString uses GMT).
626740440000 is the number of milliseconds since The Epoch, not seconds as it was in the original Unix epoch scheme. This is covered by the Time Values and Time Range section of the specification.
If you want to parse your string as UTC (loosely, GMT), add a Z to the end of it indicating that't is in GMT.
If you want the number of seconds since The Epoch, divide +date by 1000 (perhaps rounding or flooring the result).

Date difference when year is smaller than zero

If I'm executing this:
var date = new Date("10.31");
date.setFullYear(-125);
the output of date is Sun Oct 31 -125 00:00:00 GMT+0200 (W. Europe Summer Time)
If I check this on wolframalpha the day seems to be tuesday.
Can someone explain why not the same day is displayed by both source?

The reason for the difference between JavaScript and wolframalpha website is that JavaScript is calculating the years mathematically, so it includes the year zero. Try to set the year to zero in JavaScript and you will see that it works. However, there is no such a thing as year zero, and the year before year 1 is year 1 BC. Try to set the year to zero on wolframalpha website and you get an error, while it automatically converts all negative years to years BC. This is the correct behavior.
To get the BC years in JavaScript, add 1 to every year below 1. So year 0 becomes 1BC, and year -125 becomes 126BC. In JavaScript this gives you Sunday, and 126BC on wolframalpha website gives you Sunday too. 125BC gives you Tuesday on wolframalpha website, and -124 gives you the same in JavaScript.
var date = new Date();
date.setFullYear(-124);
date.setMonth(9);
date.setDate(31);
console.log(date.toString());
date.setFullYear(-125);
console.log(date.toString());

negative years in javascript do produce a BC date but it's kind of a poor design. Wolfram Alpha is probably correct. See this answer for more: Why does Date accept negative values?

Javascript dates start in 1970.
Let's do a quick count.
(new Date()).setYear(-125); //returns -66085584766591 (milliseconds from time 0)
//Let's convert those milliseconds in years...
//-66085584766591 = -2095,56 (years???)
As you can see, you can't rely on negative dates in Javascript.

Javascript Parsed Date [duplicate]

This question already has an answer here:
HTML Input type datetime-local setting the wrong time-zone
(1 answer)
Closed 7 years ago.
I'm writing a MVC 5 web application. Into this, I have multiple lists that I propagate and manage through javascript and jquery (one dataset, dependent select controls, and adding ajax callbacks would complicate it unnecessarily.)
The issue I have is: I have a hidden for field formatted to ISO 8601. I run into issues when I display the date in the user's local time, I get a shifted date.
So if the date were stated as: 01-01-2009 (in iso 8601 format: 2009-01-01), the user sees: 12-31-2008.
When I parse the date I'm using:
this.date = new Date(Date.parse(originalString));
/* ^- Date.parse is giving me a number. */
To display the text of the date I am using:
admin.date.toLocaleDateString().Concat(...
Do I need to do any sort of patch-up to adjust things to the proper time-zone? The date, when using console.log(admin.date); shows the original 2009-01-01
I'm thinking there's some parameter I'm not specifying correctly in the toLocaleDateString, but my familiarity level with it is low.
Edit: The goal is to prevent the date shift. All we store is the date, the time aspect is dropped. We have multiple time-zones posting to this database, and the goal is: We use the date of the person who posted it, time dropped. Were the date May 01, 2015, I want anyone who sees that date to see May 01, 2015, the 'toLocaleDateString' is merely a means to get it to appear format correct for their region. So someone who views dates as yyyy-mm-dd will see it properly.

Based on the documentation for Date.parse:
The Date.parse() method parses a string representation of a date, and returns the number of milliseconds since January 1, 1970, 00:00:00 UTC.
You are getting back the epoch time in UTC for your parsed date string hence why the date is off for local times. So, you would need to know the time difference between the local time and UTC which Date.getTimezoneOffset provides (in minutes) in order to set the correct date for the local time:
> var date = new Date(Date.parse('2009-01-01'));
undefined
> date;
Wed Dec 31 2008 19:00:00 GMT-0500 (EST)
> date.getTimezoneOffset();
300
> date.setMinutes(date.getTimezoneOffset());
1230786000000
> date;
Thu Jan 01 2009 00:00:00 GMT-0500 (EST)
One thing to note though is:
...the offset is positive if the local timezone is behind UTC and negative if it is ahead.
So you might need to take care for locales where the value is negative if this applies to your application. If so maybe just omitting negative values would be enough since the date should be the same if a locale's timezone is ahead of midnight UTC.
EDIT: To compensate for possible issues with daylight savings time:
> var dateVals = String.prototype.split.call('2009-01-01', '-');
undefined
> var date = new Date(dateVals[0], dateVals[1] - 1, dateVals[2]);
undefined
> date
Thu Jan 01 2009 00:00:00 GMT-0500 (EST)

How to calculate midnight for the local day from UTC time [duplicate]

This question already has answers here:
What is the best way to initialize a JavaScript Date to midnight?
(10 answers)
Closed 8 years ago.
I am using Javascript for Parse.com Cloud Code.
According to Parse.com they return UTC time. I am in EDT (GMT -4)
I'm trying to get today's date at midnight to no avail.
Here is my code:
var date = new Date();
var startDay = Math.floor((date.setUTCHours(4,0,0,0) / 1000));
So before 8pm on each day, the code returns today's date at midnight which is what I want. However, after 8pm it returns tomorrow's date at midnight. I believe the reason is due to the UTC date changing to Today+1 at midnight. But I cant figure out how to resolve this issue in a way that I get my local date at midgnight.
PS:
I also tried setHours(4,0,0,0) in vain.
If I use setUTCHours(0,0,0,0) it returns today's date at 8pm
Thank you for your help.

It's doing everything correct.
Think about it from UTC's point of view. setUTCHours(0,0,0,0) will always set it to midnight that day.
From your point of view though (GMT-4), setting the date to midnight (UTC) at 8pm (GMT-4) appears to go a day forward.
This is because when you call date.setUTCHours(), it first converts that time to UTC, then sets the hours. If you create the date on May 18th, 8pm GMT-4, then call setUTCHours(), it will first convert that date to May 19th, 12am UTC. Then it will perform the hour change.
Here's what you can do to make sure it returns midnight on the same day as the user's timezone:
const date = new Date();
// Convert to midnight in your timezone first
date.setHours(0,0,0,0);
// Convert to midnight UTC
date.setUTCHours(0,0,0,0);

missing something with my epoch date conversion

I'm splitting an array, when I take the middle of the array which is reporting as epoch date in milliseconds. I'm testing the date using Epoch Converter and its valid.
I run the date() object and multiply by 1000 to adjust but I'm getting year 4000. I've switched to division just to test if I'm getting too large of a number the year is correct but the day and months are wrong....I've got to be missing something simple:
var jEtrim = item.DTM.split(/[(-]/);
var date = new Date(jEtrim[1] *1000);
sample output: Thu Jan 08 44037 07:03:20 GMT-0500 (Eastern Standard Time)
Here's the jEtrim: ["/Date", "1343151455000", "0400)/"]
Thanks in advance

Date takes its argument in milliseconds already, so you will not need to multiply by 1000. You will only need to convert it to a number:
new Date(+"1343151455000")