I'm working in a from who has a date field and by default it shows the current date.
I set the date using this:
var date = new Date(); = Tue May 25 2021 17:06:01 GMT-0600 (Mountain Daylight Time) {}**
Everything works fine, but when I send the data to the controller, the JSON automatically converts it to ISO and the date received by the controller is 6 hours in advance.
I understand a little bit the context about GMT-0006 (my current timezone is 6 hours more than the 0 timezone), and the fact that my controllers received the date in ISO format because when I converted to ISO format is the same problem
date.toISOString() = "2021-05-25T23:06:01.861Z" (6 hours in advance)
so my question is, there is a way to create a date that allows me to use .toISOString() and keep the same?
or create a date with my current hour but -0000 so when I convert it to toISOString keeps the same?
This question already has answers here:
Javascript: parse a string to Date as LOCAL time zone
(3 answers)
Closed 3 years ago.
why its showing past day date
var date = new Date('2020-01-01');
console.log(date)
Tue Dec 31 2019 19:00:00 GMT-0500 (Eastern Standard Time)
Because of your timezone settings (Easter Standard time is GMT -0500 therefore 5 hours before 2020-01-01).
Javascript Date object are timestamps - they merely contain a number
of milliseconds since the epoch. There is no timezone info in a Date
object. Which calendar date (day, minutes, seconds) this timestamp
represents is a matter of the interpretation (one of to...String
methods).
Basically it is the toString method that converts the date to your local timezone.
Source
This question already has answers here:
Why does Date.parse give incorrect results?
(11 answers)
Closed 7 years ago.
I was executing below statement under nodejs repl and i was getting two different result for same date
var dateStr1 = "2015/03/31";
var dateStr2 = "2015-03-31";
var date1 = new Date(dateStr1);//gives Tue Mar 31 2015 00:00:00 GMT+0530 (IST)
var date2 = new Date(dateStr2);//gives Tue Mar 31 2015 05:30:00 GMT+0530 (IST)
In the 1st one hour,min,seconds are all zeros while in the 2nd one by default hour,min is getting set to as a timezone hour,min which is 5:30
It boils down to how Date.parse() handles the ISO-8601 date format.
The date time string may be in ISO 8601 format. For example, "2011-10-10" (just date) or "2011-10-10T14:48:00" (date and time) can be passed and parsed. The UTC time zone is used to interpret arguments in ISO 8601 format that do not contain time zone information (note that ECMAScript ed 6 draft specifies that date time strings without a time zone are to be treated as local, not UTC)
Your first date format 2015/03/31 is assumed to be March 31st, 2015 at 12am in your current time zone.
Your second date format 2015-03-31 is seen as ISO-8601 and is assumed to be March 31st, 2015 at 12am UTC time zone.
The "Differences in assumed time zone" heading from the linked documentation goes into a bit more detail:
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. Therefore Date objects produced using those strings will represent different moments in time 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 (this behavior is changed in ECMAScript ed 6 so that both will be treated as local).
The first string, "2015/03/31", is an unsupported format according to the ECMAScript standard. Whenever an unsupported value is passed to the constructor its behaviour is implementation dependent, i.e. the standard doesn't say what the implementation must do. Some browsers, like Firefox, try to guess what the format is and apparently it creates a date object with that date at midnight local time. Other browsers may return NaN or interpret the parts differently.
The second string, "2015-03-31", is a properly formatted ISO 8601 date. For these strings there are well defined rules and all browsers will interpret it as that date, midnight, UTC.
This question already has answers here:
Create a Date with a set timezone without using a string representation
(29 answers)
Closed 4 years ago.
Why does this give me september 30 rather than oct 1?
var dob = new Date("1999-10-01")
console.log(dob.toString())
You are creating a Date new Date("1999-10-01") and parsing it with the method toString() which is using your local timezone:
var dob = new Date("1999-10-01")
console.log(dob)
console.log(dob.toISOString())
console.log('My local time is different!')
console.log(dob.toLocaleString('es-AR', { timeZone: 'America/Buenos_Aires', timeZoneName: 'long'}))
console.log('Your local time is different?')
console.log(dob.toString())
The format you are using is a subset of ISO 8601
When no timezone designator is specified offset Zulu (UTC) is implied in the date constructor.
http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.15
All numbers must be base 10. If the MM or DD fields are absent “01” is
used as the value. If the HH, mm, or ss fields are absent “00” is used
as the value and the value of an absent sss field is “000”. The value
of an absent time zone offset is “Z”.
In other words, the format that you are using is valid and it denotes a date-time in UTC. What you are seeing in the console is that time represented in your timezone.
const date = new Date("1999-10-01");
console.log(date.toLocaleDateString('ar-EG'));
console.log(date.toString());
console.log(date.toISOString());
I'm trying to pass both date strings to new Date(t).
I expect both strings represent the same time, after all, if I omit the time, shouldn't it be midnight of that day?
But while,
new Date("2016-02-16 00:00")
returns 2016-02-16, midnight, local time as expected,
new Date("2016-02-16")
returns 2016-02-16, midnight UTC, which is wrong, or at least not what I expected given what the other string parses as.
I would understand it if they would both have the same behavior, whether it is to return the time as local time, or as UTC, but it seems very inconsistent why they return different things like this.
As a workaround, whenever I encounter a date that has no corresponding timestamp I can append " 00:00" to get consistent behavior, but it seems like this is rather fragile.
I am getting this value from an INPUT element, of type 'datetime-local' so it seems especially inconsistent that I have to work around a value returned by a page element.
Am I doing something wrong, or should I be doing something differently?
It's what the ES5.1 specification says to do:
The value of an absent time zone offset is “Z”.
It also says:
The function first attempts to parse the format of the String according to the rules called out in Date Time String Format (15.9.1.15). If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats.
Since the format requires a T separator between date and time, the valid times go to UTC:
> new Date("2016-02-16T00:00:00")
Tue Feb 16 2016 01:00:00 GMT+0100 (CET)
> new Date("2016-02-16")
Tue Feb 16 2016 01:00:00 GMT+0100 (CET)
...while in node.js, an invalid time (without the T separator) seems to go to the implementation specific localtime:
> new Date("2016-02-16 00:00:00")
Tue Feb 16 2016 00:00:00 GMT+0100 (CET)
Note that ES6 changed this, in the same part of the documentation it changes to:
If the time zone offset is absent, the date-time is interpreted as a local time.
The joy of breaking changes.
Edit
According to TC39, the specification is meant to be interpreted as date and time strings without a time zone (e.g. "2016-02-16T00:00:00") are treated as local (per ISO 8601), but date only strings (e.g. "2016-02-16") as UTC (which is inconsistent with ISO 8601).
According to the specifications:
The function first attempts to parse the format of the String
according to the rules called out in Date Time String Format
(15.9.1.15). If the String does not conform to that format the
function may fall back to any implementation-specific heuristics or
implementation-specific date formats.
And Date Time String Formats accept 2016-02-16 as a valid date
This format includes date-only forms:
YYYY
YYYY-MM
YYYY-MM-DD
[...] If the HH, mm, or ss fields are absent “00” is used as the value
and the value of an absent sss field is “000”. The value of an absent
time zone offset is “Z”.
Thus 2016-02-16 translates to 2016-02-16T00:00:00.000Z.
The other date 2016-02-16 00:00 does not conform to the format and therefore its parsing is implementation specific. Apparently, such dates are treated as having local time zone and your example date will return different values depending on time zone:
/* tz = +05:00 */ new Date("2016-02-16 00:00").toISOString() // 2016-02-15T19:00:00.000Z
/* tz = -08:00 */ new Date("2016-02-16 00:00").toISOString() // 2016-02-16T08:00:00.000Z
Summary:
For conforming date time formats the behavior is well defined — in the absence of time zone offset the date string is treated as UTC (ES5) or local (ES6).
For non-conforming date time formats the behavior is implementation specific — in the absence of time zone offset the usual behavior is to treat the date as local.
As a matter of fact, the implementation could choose to return NaN instead of trying to parse non-conforming dates. Just test your code in Internet Explorer 11 ;)
You are perhaps running into a differences between ES5, ES6 implementations and your expected result. Per Date.parse at MDN, "especially across different ECMAScript implementations where strings like "2015-10-12 12:00:00" may be parsed to as NaN, UTC or local timezone" is significant.
Additional testing in Firefox 44 and IE 11 revealed they both return a date object for new Date("2016-02-16 00:00"), which object returns NaN when atttempting to get a date component value, and whose toString value is
"Invalid Date" (not "NaN"). Hence appending " 00:00 to get consistent behavior" can easily break in different browsers.
As noted in other answers new Date("2016-02-16") uses a timezone offset of zero by default, producing midnight UTC instead of local.
Per DateParser::Parse() of V8 source codes for Chrome.
ES5 ISO 8601 dates:
[('-'|'+')yy]yyyy[-MM[-DD]][THH:mm[:ss[.sss]][Z|(+|-)hh:mm]]
An unsigned number followed by ':' is a time value, and is added to the TimeComposer.
timezone defaults to Z if missing
> new Date("2016-02-16 00:00")
Tue Feb 16 2016 00:00:00 GMT+0800 (China Standard Time)
A string that matches both formats (e.g. 1970-01-01) will be parsed as an ES5 date-time string - which means it will default to UTC time-zone. That's unavoidable if following the ES5 specification.
> new Date("2016-02-16")
Tue Feb 16 2016 08:00:00 GMT+0800 (China Standard Time)
returns 2016-02-16, midnight UTC, which is wrong, or at least not what I expected given what the other string parses as.
It adds the timezone offset to the 00:00
new Date("2016-02-16") outputs Tue Feb 16 2016 05:30:00 GMT+0530 (India Standard Time)
My timezone being IST with an offset value (in minutes) +330, so it added 330 minutes to 00:00.
As per ecma-262, section 20.3.3.2 Date.parse ( string )
If ToString results in an abrupt completion the Completion Record is
immediately returned. Otherwise, parse interprets the resulting String
as a date and time; it returns a Number, the UTC time value
corresponding to the date and time. The String may be interpreted as a
local time, a UTC time, or a time in some other time zone, depending
on the contents of the String.
When you explicitly set the time-units new Date("2016-02-16 00:00") it wll use set that as hours and minutes,
Otherwise as stated here in 20.3.1.16
If the time zone offset is absent, the date-time is interpreted as a
local time.