Date.setDate ensuring consistent time (mode?) DST vs Standard
I have this function that returns a new Date
instance with a number of days added or subtracted from a passed Date
object.
function daysFrom(date, numDays) {
var retDate = new Date();
retDate.setDate(date.getDate() + numDays);
return retDate;
}
But right now (in Pacific time zone), if I pass a date from September 19, 2018, my two dates are inconsistent in Standard vs Daylight Saving Time.
var endDate = new Date(Date.parse('19 September 2018 00:12:00 GMT'));
var startDate = daysFrom(endDate, -5);
console.log(startDate, endDate);
// Tue Sep 18 2018 17:12:00 GMT-0700 (Pacific Daylight Time) Tue Nov 13 2018 20:05:02 GMT-0800 (Pacific Standard Time)
I guess they would be different because my returned date was instantiated today, since we're not in DST, but what's the simplest way to ensure the returned date is the correct mode for the time of year? In 2019, DST will start on March 10, so if I subtract x
number of days from that, I would expect the time mode (whatever it's called) to be Standard, not DST.
And what's the mode called (DST vs Standard)?
Using current release of Chrome browser.
javascript date
add a comment |
I have this function that returns a new Date
instance with a number of days added or subtracted from a passed Date
object.
function daysFrom(date, numDays) {
var retDate = new Date();
retDate.setDate(date.getDate() + numDays);
return retDate;
}
But right now (in Pacific time zone), if I pass a date from September 19, 2018, my two dates are inconsistent in Standard vs Daylight Saving Time.
var endDate = new Date(Date.parse('19 September 2018 00:12:00 GMT'));
var startDate = daysFrom(endDate, -5);
console.log(startDate, endDate);
// Tue Sep 18 2018 17:12:00 GMT-0700 (Pacific Daylight Time) Tue Nov 13 2018 20:05:02 GMT-0800 (Pacific Standard Time)
I guess they would be different because my returned date was instantiated today, since we're not in DST, but what's the simplest way to ensure the returned date is the correct mode for the time of year? In 2019, DST will start on March 10, so if I subtract x
number of days from that, I would expect the time mode (whatever it's called) to be Standard, not DST.
And what's the mode called (DST vs Standard)?
Using current release of Chrome browser.
javascript date
The use of Date.parse innew Date(Date.parse('19 September 2018 00:12:00 GMT'))
is redundant. Also, that is not a format supported by ECMAScript, so parsing is implementation dependent.
– RobG
Nov 19 at 9:02
add a comment |
I have this function that returns a new Date
instance with a number of days added or subtracted from a passed Date
object.
function daysFrom(date, numDays) {
var retDate = new Date();
retDate.setDate(date.getDate() + numDays);
return retDate;
}
But right now (in Pacific time zone), if I pass a date from September 19, 2018, my two dates are inconsistent in Standard vs Daylight Saving Time.
var endDate = new Date(Date.parse('19 September 2018 00:12:00 GMT'));
var startDate = daysFrom(endDate, -5);
console.log(startDate, endDate);
// Tue Sep 18 2018 17:12:00 GMT-0700 (Pacific Daylight Time) Tue Nov 13 2018 20:05:02 GMT-0800 (Pacific Standard Time)
I guess they would be different because my returned date was instantiated today, since we're not in DST, but what's the simplest way to ensure the returned date is the correct mode for the time of year? In 2019, DST will start on March 10, so if I subtract x
number of days from that, I would expect the time mode (whatever it's called) to be Standard, not DST.
And what's the mode called (DST vs Standard)?
Using current release of Chrome browser.
javascript date
I have this function that returns a new Date
instance with a number of days added or subtracted from a passed Date
object.
function daysFrom(date, numDays) {
var retDate = new Date();
retDate.setDate(date.getDate() + numDays);
return retDate;
}
But right now (in Pacific time zone), if I pass a date from September 19, 2018, my two dates are inconsistent in Standard vs Daylight Saving Time.
var endDate = new Date(Date.parse('19 September 2018 00:12:00 GMT'));
var startDate = daysFrom(endDate, -5);
console.log(startDate, endDate);
// Tue Sep 18 2018 17:12:00 GMT-0700 (Pacific Daylight Time) Tue Nov 13 2018 20:05:02 GMT-0800 (Pacific Standard Time)
I guess they would be different because my returned date was instantiated today, since we're not in DST, but what's the simplest way to ensure the returned date is the correct mode for the time of year? In 2019, DST will start on March 10, so if I subtract x
number of days from that, I would expect the time mode (whatever it's called) to be Standard, not DST.
And what's the mode called (DST vs Standard)?
Using current release of Chrome browser.
javascript date
javascript date
edited Nov 19 at 4:37
asked Nov 19 at 4:05
BBaysinger
1,59542258
1,59542258
The use of Date.parse innew Date(Date.parse('19 September 2018 00:12:00 GMT'))
is redundant. Also, that is not a format supported by ECMAScript, so parsing is implementation dependent.
– RobG
Nov 19 at 9:02
add a comment |
The use of Date.parse innew Date(Date.parse('19 September 2018 00:12:00 GMT'))
is redundant. Also, that is not a format supported by ECMAScript, so parsing is implementation dependent.
– RobG
Nov 19 at 9:02
The use of Date.parse in
new Date(Date.parse('19 September 2018 00:12:00 GMT'))
is redundant. Also, that is not a format supported by ECMAScript, so parsing is implementation dependent.– RobG
Nov 19 at 9:02
The use of Date.parse in
new Date(Date.parse('19 September 2018 00:12:00 GMT'))
is redundant. Also, that is not a format supported by ECMAScript, so parsing is implementation dependent.– RobG
Nov 19 at 9:02
add a comment |
3 Answers
3
active
oldest
votes
You need to clone the end date instead of initializing it with the current date:
function daysFrom(date, numDays) {
var retDate = new Date(date.getTime());
retDate.setDate(date.getDate() + numDays);
return retDate;
}
var endDate = new Date(Date.parse('19 September 2018 00:12:00 GMT'));
var startDate = daysFrom(endDate, -5);
console.log(startDate, endDate);
As for the default string representation of a date object, it's implementation dependent (up to ECMAScript 2018), so at the discretion of your browser.
From MDN:
Until ECMAScript 2018 (edition 9), the format of the string returned
byDate.prototype.toString
was implementation dependent. Therefore it
should not be relied upon to be in the specified format.
Close, but I think the mode would always be the same as the one passed.
– BBaysinger
Nov 19 at 4:16
@BBaysinger See my update.
– Robby Cornelissen
Nov 19 at 4:18
Is that saying there isn't a way to know the correct time mode for the returned date?
– BBaysinger
Nov 19 at 4:19
JavaScript date objects do not contain timezone information.
– Robby Cornelissen
Nov 19 at 4:20
2
Of course it's possible to calculate a timezone-specific date representation. After all, that is what your browser does when it spits out thosePacific Daylight Time
strings. I'm just saying that the date object itself doesn't contain that information.
– Robby Cornelissen
Nov 19 at 4:57
|
show 2 more comments
I think you mean to initialize retDate to date?
function daysFrom(date, numDays) {
var retDate = new Date(date);
retDate.setDate(date.getDate() + numDays);
return retDate;
}
Close, but I think the mode would always be the same as the one passed.
– BBaysinger
Nov 19 at 4:17
Indeed. Thanks @RobG, new superpower to mess with dates unlocked. :-) . Answer updated.
– Jim B.
Nov 19 at 15:06
add a comment |
...but what's the simplest way to ensure the returned date is the correct mode for the time of year? In 2019, DST will start on March 10, so if I subtract x number of days from that, I would expect the time mode (whatever it's called) to be Standard, not DST.
There is no "mode", Date objects do not have a timezone offset. The offset comes from the host system for the date that getTimezoneOffset is called on, it's not stored with the Date.
Until recently, implementations applied current timezone offset settings as if they'd always existed. However, with ECMAScript 2015 it was recommended to support historic changes, and with ECMAScript 2018 it is required that they reflect historic changes as accurately as they can. That change hasn't been fully implemented across all implementations, so you may get differences where the offset or daylight saving rules have changed from those that are currently implemented.
And what's the mode called (DST vs Standard)?
ECMAScript refers to "daylight saving time" and "local timezone adjustment", but it also says "local standard time" when explicitly differentiating between local (standard) time and daylight saving time.
More generally, the typical summer offset is called "daylight saving time" or "summer time" and everything else is "standard time". There is no standardisation on timezone names (check a few browsers, they're all over the place) so anything will do as long as it's consistent and not ambiguous.
The last question wasn’t about JavaScript date objects, but dates in general.
– BBaysinger
Nov 19 at 21:15
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53368161%2fdate-setdate-ensuring-consistent-time-mode-dst-vs-standard%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
You need to clone the end date instead of initializing it with the current date:
function daysFrom(date, numDays) {
var retDate = new Date(date.getTime());
retDate.setDate(date.getDate() + numDays);
return retDate;
}
var endDate = new Date(Date.parse('19 September 2018 00:12:00 GMT'));
var startDate = daysFrom(endDate, -5);
console.log(startDate, endDate);
As for the default string representation of a date object, it's implementation dependent (up to ECMAScript 2018), so at the discretion of your browser.
From MDN:
Until ECMAScript 2018 (edition 9), the format of the string returned
byDate.prototype.toString
was implementation dependent. Therefore it
should not be relied upon to be in the specified format.
Close, but I think the mode would always be the same as the one passed.
– BBaysinger
Nov 19 at 4:16
@BBaysinger See my update.
– Robby Cornelissen
Nov 19 at 4:18
Is that saying there isn't a way to know the correct time mode for the returned date?
– BBaysinger
Nov 19 at 4:19
JavaScript date objects do not contain timezone information.
– Robby Cornelissen
Nov 19 at 4:20
2
Of course it's possible to calculate a timezone-specific date representation. After all, that is what your browser does when it spits out thosePacific Daylight Time
strings. I'm just saying that the date object itself doesn't contain that information.
– Robby Cornelissen
Nov 19 at 4:57
|
show 2 more comments
You need to clone the end date instead of initializing it with the current date:
function daysFrom(date, numDays) {
var retDate = new Date(date.getTime());
retDate.setDate(date.getDate() + numDays);
return retDate;
}
var endDate = new Date(Date.parse('19 September 2018 00:12:00 GMT'));
var startDate = daysFrom(endDate, -5);
console.log(startDate, endDate);
As for the default string representation of a date object, it's implementation dependent (up to ECMAScript 2018), so at the discretion of your browser.
From MDN:
Until ECMAScript 2018 (edition 9), the format of the string returned
byDate.prototype.toString
was implementation dependent. Therefore it
should not be relied upon to be in the specified format.
Close, but I think the mode would always be the same as the one passed.
– BBaysinger
Nov 19 at 4:16
@BBaysinger See my update.
– Robby Cornelissen
Nov 19 at 4:18
Is that saying there isn't a way to know the correct time mode for the returned date?
– BBaysinger
Nov 19 at 4:19
JavaScript date objects do not contain timezone information.
– Robby Cornelissen
Nov 19 at 4:20
2
Of course it's possible to calculate a timezone-specific date representation. After all, that is what your browser does when it spits out thosePacific Daylight Time
strings. I'm just saying that the date object itself doesn't contain that information.
– Robby Cornelissen
Nov 19 at 4:57
|
show 2 more comments
You need to clone the end date instead of initializing it with the current date:
function daysFrom(date, numDays) {
var retDate = new Date(date.getTime());
retDate.setDate(date.getDate() + numDays);
return retDate;
}
var endDate = new Date(Date.parse('19 September 2018 00:12:00 GMT'));
var startDate = daysFrom(endDate, -5);
console.log(startDate, endDate);
As for the default string representation of a date object, it's implementation dependent (up to ECMAScript 2018), so at the discretion of your browser.
From MDN:
Until ECMAScript 2018 (edition 9), the format of the string returned
byDate.prototype.toString
was implementation dependent. Therefore it
should not be relied upon to be in the specified format.
You need to clone the end date instead of initializing it with the current date:
function daysFrom(date, numDays) {
var retDate = new Date(date.getTime());
retDate.setDate(date.getDate() + numDays);
return retDate;
}
var endDate = new Date(Date.parse('19 September 2018 00:12:00 GMT'));
var startDate = daysFrom(endDate, -5);
console.log(startDate, endDate);
As for the default string representation of a date object, it's implementation dependent (up to ECMAScript 2018), so at the discretion of your browser.
From MDN:
Until ECMAScript 2018 (edition 9), the format of the string returned
byDate.prototype.toString
was implementation dependent. Therefore it
should not be relied upon to be in the specified format.
function daysFrom(date, numDays) {
var retDate = new Date(date.getTime());
retDate.setDate(date.getDate() + numDays);
return retDate;
}
var endDate = new Date(Date.parse('19 September 2018 00:12:00 GMT'));
var startDate = daysFrom(endDate, -5);
console.log(startDate, endDate);
function daysFrom(date, numDays) {
var retDate = new Date(date.getTime());
retDate.setDate(date.getDate() + numDays);
return retDate;
}
var endDate = new Date(Date.parse('19 September 2018 00:12:00 GMT'));
var startDate = daysFrom(endDate, -5);
console.log(startDate, endDate);
edited Nov 19 at 4:17
answered Nov 19 at 4:13
Robby Cornelissen
43.1k126789
43.1k126789
Close, but I think the mode would always be the same as the one passed.
– BBaysinger
Nov 19 at 4:16
@BBaysinger See my update.
– Robby Cornelissen
Nov 19 at 4:18
Is that saying there isn't a way to know the correct time mode for the returned date?
– BBaysinger
Nov 19 at 4:19
JavaScript date objects do not contain timezone information.
– Robby Cornelissen
Nov 19 at 4:20
2
Of course it's possible to calculate a timezone-specific date representation. After all, that is what your browser does when it spits out thosePacific Daylight Time
strings. I'm just saying that the date object itself doesn't contain that information.
– Robby Cornelissen
Nov 19 at 4:57
|
show 2 more comments
Close, but I think the mode would always be the same as the one passed.
– BBaysinger
Nov 19 at 4:16
@BBaysinger See my update.
– Robby Cornelissen
Nov 19 at 4:18
Is that saying there isn't a way to know the correct time mode for the returned date?
– BBaysinger
Nov 19 at 4:19
JavaScript date objects do not contain timezone information.
– Robby Cornelissen
Nov 19 at 4:20
2
Of course it's possible to calculate a timezone-specific date representation. After all, that is what your browser does when it spits out thosePacific Daylight Time
strings. I'm just saying that the date object itself doesn't contain that information.
– Robby Cornelissen
Nov 19 at 4:57
Close, but I think the mode would always be the same as the one passed.
– BBaysinger
Nov 19 at 4:16
Close, but I think the mode would always be the same as the one passed.
– BBaysinger
Nov 19 at 4:16
@BBaysinger See my update.
– Robby Cornelissen
Nov 19 at 4:18
@BBaysinger See my update.
– Robby Cornelissen
Nov 19 at 4:18
Is that saying there isn't a way to know the correct time mode for the returned date?
– BBaysinger
Nov 19 at 4:19
Is that saying there isn't a way to know the correct time mode for the returned date?
– BBaysinger
Nov 19 at 4:19
JavaScript date objects do not contain timezone information.
– Robby Cornelissen
Nov 19 at 4:20
JavaScript date objects do not contain timezone information.
– Robby Cornelissen
Nov 19 at 4:20
2
2
Of course it's possible to calculate a timezone-specific date representation. After all, that is what your browser does when it spits out those
Pacific Daylight Time
strings. I'm just saying that the date object itself doesn't contain that information.– Robby Cornelissen
Nov 19 at 4:57
Of course it's possible to calculate a timezone-specific date representation. After all, that is what your browser does when it spits out those
Pacific Daylight Time
strings. I'm just saying that the date object itself doesn't contain that information.– Robby Cornelissen
Nov 19 at 4:57
|
show 2 more comments
I think you mean to initialize retDate to date?
function daysFrom(date, numDays) {
var retDate = new Date(date);
retDate.setDate(date.getDate() + numDays);
return retDate;
}
Close, but I think the mode would always be the same as the one passed.
– BBaysinger
Nov 19 at 4:17
Indeed. Thanks @RobG, new superpower to mess with dates unlocked. :-) . Answer updated.
– Jim B.
Nov 19 at 15:06
add a comment |
I think you mean to initialize retDate to date?
function daysFrom(date, numDays) {
var retDate = new Date(date);
retDate.setDate(date.getDate() + numDays);
return retDate;
}
Close, but I think the mode would always be the same as the one passed.
– BBaysinger
Nov 19 at 4:17
Indeed. Thanks @RobG, new superpower to mess with dates unlocked. :-) . Answer updated.
– Jim B.
Nov 19 at 15:06
add a comment |
I think you mean to initialize retDate to date?
function daysFrom(date, numDays) {
var retDate = new Date(date);
retDate.setDate(date.getDate() + numDays);
return retDate;
}
I think you mean to initialize retDate to date?
function daysFrom(date, numDays) {
var retDate = new Date(date);
retDate.setDate(date.getDate() + numDays);
return retDate;
}
edited Nov 19 at 15:04
answered Nov 19 at 4:13
Jim B.
2,6561929
2,6561929
Close, but I think the mode would always be the same as the one passed.
– BBaysinger
Nov 19 at 4:17
Indeed. Thanks @RobG, new superpower to mess with dates unlocked. :-) . Answer updated.
– Jim B.
Nov 19 at 15:06
add a comment |
Close, but I think the mode would always be the same as the one passed.
– BBaysinger
Nov 19 at 4:17
Indeed. Thanks @RobG, new superpower to mess with dates unlocked. :-) . Answer updated.
– Jim B.
Nov 19 at 15:06
Close, but I think the mode would always be the same as the one passed.
– BBaysinger
Nov 19 at 4:17
Close, but I think the mode would always be the same as the one passed.
– BBaysinger
Nov 19 at 4:17
Indeed. Thanks @RobG, new superpower to mess with dates unlocked. :-) . Answer updated.
– Jim B.
Nov 19 at 15:06
Indeed. Thanks @RobG, new superpower to mess with dates unlocked. :-) . Answer updated.
– Jim B.
Nov 19 at 15:06
add a comment |
...but what's the simplest way to ensure the returned date is the correct mode for the time of year? In 2019, DST will start on March 10, so if I subtract x number of days from that, I would expect the time mode (whatever it's called) to be Standard, not DST.
There is no "mode", Date objects do not have a timezone offset. The offset comes from the host system for the date that getTimezoneOffset is called on, it's not stored with the Date.
Until recently, implementations applied current timezone offset settings as if they'd always existed. However, with ECMAScript 2015 it was recommended to support historic changes, and with ECMAScript 2018 it is required that they reflect historic changes as accurately as they can. That change hasn't been fully implemented across all implementations, so you may get differences where the offset or daylight saving rules have changed from those that are currently implemented.
And what's the mode called (DST vs Standard)?
ECMAScript refers to "daylight saving time" and "local timezone adjustment", but it also says "local standard time" when explicitly differentiating between local (standard) time and daylight saving time.
More generally, the typical summer offset is called "daylight saving time" or "summer time" and everything else is "standard time". There is no standardisation on timezone names (check a few browsers, they're all over the place) so anything will do as long as it's consistent and not ambiguous.
The last question wasn’t about JavaScript date objects, but dates in general.
– BBaysinger
Nov 19 at 21:15
add a comment |
...but what's the simplest way to ensure the returned date is the correct mode for the time of year? In 2019, DST will start on March 10, so if I subtract x number of days from that, I would expect the time mode (whatever it's called) to be Standard, not DST.
There is no "mode", Date objects do not have a timezone offset. The offset comes from the host system for the date that getTimezoneOffset is called on, it's not stored with the Date.
Until recently, implementations applied current timezone offset settings as if they'd always existed. However, with ECMAScript 2015 it was recommended to support historic changes, and with ECMAScript 2018 it is required that they reflect historic changes as accurately as they can. That change hasn't been fully implemented across all implementations, so you may get differences where the offset or daylight saving rules have changed from those that are currently implemented.
And what's the mode called (DST vs Standard)?
ECMAScript refers to "daylight saving time" and "local timezone adjustment", but it also says "local standard time" when explicitly differentiating between local (standard) time and daylight saving time.
More generally, the typical summer offset is called "daylight saving time" or "summer time" and everything else is "standard time". There is no standardisation on timezone names (check a few browsers, they're all over the place) so anything will do as long as it's consistent and not ambiguous.
The last question wasn’t about JavaScript date objects, but dates in general.
– BBaysinger
Nov 19 at 21:15
add a comment |
...but what's the simplest way to ensure the returned date is the correct mode for the time of year? In 2019, DST will start on March 10, so if I subtract x number of days from that, I would expect the time mode (whatever it's called) to be Standard, not DST.
There is no "mode", Date objects do not have a timezone offset. The offset comes from the host system for the date that getTimezoneOffset is called on, it's not stored with the Date.
Until recently, implementations applied current timezone offset settings as if they'd always existed. However, with ECMAScript 2015 it was recommended to support historic changes, and with ECMAScript 2018 it is required that they reflect historic changes as accurately as they can. That change hasn't been fully implemented across all implementations, so you may get differences where the offset or daylight saving rules have changed from those that are currently implemented.
And what's the mode called (DST vs Standard)?
ECMAScript refers to "daylight saving time" and "local timezone adjustment", but it also says "local standard time" when explicitly differentiating between local (standard) time and daylight saving time.
More generally, the typical summer offset is called "daylight saving time" or "summer time" and everything else is "standard time". There is no standardisation on timezone names (check a few browsers, they're all over the place) so anything will do as long as it's consistent and not ambiguous.
...but what's the simplest way to ensure the returned date is the correct mode for the time of year? In 2019, DST will start on March 10, so if I subtract x number of days from that, I would expect the time mode (whatever it's called) to be Standard, not DST.
There is no "mode", Date objects do not have a timezone offset. The offset comes from the host system for the date that getTimezoneOffset is called on, it's not stored with the Date.
Until recently, implementations applied current timezone offset settings as if they'd always existed. However, with ECMAScript 2015 it was recommended to support historic changes, and with ECMAScript 2018 it is required that they reflect historic changes as accurately as they can. That change hasn't been fully implemented across all implementations, so you may get differences where the offset or daylight saving rules have changed from those that are currently implemented.
And what's the mode called (DST vs Standard)?
ECMAScript refers to "daylight saving time" and "local timezone adjustment", but it also says "local standard time" when explicitly differentiating between local (standard) time and daylight saving time.
More generally, the typical summer offset is called "daylight saving time" or "summer time" and everything else is "standard time". There is no standardisation on timezone names (check a few browsers, they're all over the place) so anything will do as long as it's consistent and not ambiguous.
edited Nov 20 at 0:01
answered Nov 19 at 20:35
RobG
96.8k19102145
96.8k19102145
The last question wasn’t about JavaScript date objects, but dates in general.
– BBaysinger
Nov 19 at 21:15
add a comment |
The last question wasn’t about JavaScript date objects, but dates in general.
– BBaysinger
Nov 19 at 21:15
The last question wasn’t about JavaScript date objects, but dates in general.
– BBaysinger
Nov 19 at 21:15
The last question wasn’t about JavaScript date objects, but dates in general.
– BBaysinger
Nov 19 at 21:15
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53368161%2fdate-setdate-ensuring-consistent-time-mode-dst-vs-standard%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
The use of Date.parse in
new Date(Date.parse('19 September 2018 00:12:00 GMT'))
is redundant. Also, that is not a format supported by ECMAScript, so parsing is implementation dependent.– RobG
Nov 19 at 9:02