Date.setDate ensuring consistent time (mode?) DST vs Standard












2














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.










share|improve this question
























  • 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
















2














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.










share|improve this question
























  • 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














2












2








2







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.










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 19 at 4:37

























asked Nov 19 at 4:05









BBaysinger

1,59542258




1,59542258












  • 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
















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












3 Answers
3






active

oldest

votes


















1














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
by Date.prototype.toString was implementation dependent. Therefore it
should not be relied upon to be in the specified format.







share|improve this answer























  • 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 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



















0














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;
}





share|improve this answer























  • 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



















0















...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.






share|improve this answer























  • The last question wasn’t about JavaScript date objects, but dates in general.
    – BBaysinger
    Nov 19 at 21:15











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
});


}
});














draft saved

draft discarded


















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









1














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
by Date.prototype.toString was implementation dependent. Therefore it
should not be relied upon to be in the specified format.







share|improve this answer























  • 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 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
















1














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
by Date.prototype.toString was implementation dependent. Therefore it
should not be relied upon to be in the specified format.







share|improve this answer























  • 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 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














1












1








1






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
by Date.prototype.toString was implementation dependent. Therefore it
should not be relied upon to be in the specified format.







share|improve this answer














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
by Date.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);






share|improve this answer














share|improve this answer



share|improve this answer








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 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


















  • 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 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
















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













0














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;
}





share|improve this answer























  • 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
















0














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;
}





share|improve this answer























  • 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














0












0








0






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;
}





share|improve this answer














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;
}






share|improve this answer














share|improve this answer



share|improve this answer








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


















  • 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











0















...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.






share|improve this answer























  • The last question wasn’t about JavaScript date objects, but dates in general.
    – BBaysinger
    Nov 19 at 21:15
















0















...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.






share|improve this answer























  • The last question wasn’t about JavaScript date objects, but dates in general.
    – BBaysinger
    Nov 19 at 21:15














0












0








0







...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.






share|improve this answer















...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.







share|improve this answer














share|improve this answer



share|improve this answer








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


















  • 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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

If I really need a card on my start hand, how many mulligans make sense? [duplicate]

Alcedinidae

Can an atomic nucleus contain both particles and antiparticles? [duplicate]