在我的Java脚本应用程序中，我以这样的格式存储日期:
2011-09-24
现在，当我尝试使用上面的值创建一个新的Date对象(这样我就可以以不同的格式检索日期)时，日期总是返回一天。见下文:
var date = new Date("2011-09-24");
console.log(date);
日志:
Fri Sep 23 2011 20:00:00 GMT-0400 (Eastern Daylight Time)
当前回答
您正在使用ISO日期字符串格式，根据此页，将导致使用UTC时区构造日期:
注意:使用date构造函数(和 日期。解析，它们是等效的)是强烈不鼓励的，因为 浏览器差异和不一致。支持RFC 2822格式 字符串只是按照惯例。对ISO 8601格式的支持有所不同 只有日期的字符串(例如:"1970-01-01")被视为UTC，而不是 当地。
如果文本格式不同，例如“Jan 01 1970”，那么(至少在我的机器上)它使用您的本地时区。
其他回答
我解析ISO日期而不受时区困扰的解决方案是在解析它之前在结尾添加“T12:00:00”，因为当格林威治的中午时，整个世界都在同一天:
function toDate(isoDateString) {
// isoDateString is a string like "yyyy-MM-dd"
return new Date(`${isoDateString}T12:00:00`);
}
之前:
> new Date("2020-10-06")
> Date Mon Oct 05 2020 14:00:00 GMT-1000 (heure normale d’Hawaii - Aléoutiennes)
后:
> toDate("2020-10-06")
> Date Tue Oct 06 2020 12:00:00 GMT-1000 (heure normale d’Hawaii - Aléoutiennes)
当我的客户使用大西洋标准时间时，我遇到了这个问题。客户端检索到的日期值是“2018-11-23”，当代码将其传递到new date(“2018-11-23”)时，客户端的输出是前一天的日期。我创建了一个实用函数，如代码片段所示，它规范化了日期，向客户端提供了预期的日期。
日期。
var normalizeDate = function(date) { date.setMinutes(date.getMinutes() + date.getTimezoneOffset()); return date; }; var date = new Date("2018-11-23"); document.getElementById("default").textContent = date; document.getElementById("normalized").textContent = normalizeDate(date); <h2>Calling new Date("2018-11-23")</h2> <div> <label><b>Default</b> : </label> <span id="default"></span> </div> <hr> <div> <label><b>Normalized</b> : </label> <span id="normalized"></span> </div>
要规范化日期并消除不需要的偏移量(在这里测试:https://jsfiddle.net/7xp1xL5m/):
var doo = new Date("2011-09-24");
console.log( new Date( doo.getTime() + Math.abs(doo.getTimezoneOffset()*60000) ) );
// Output: Sat Sep 24 2011 00:00:00 GMT-0400 (Eastern Daylight Time)
这也实现了同样的效果，并归功于@tpartee(在这里测试:https://jsfiddle.net/7xp1xL5m/1/):
var doo = new Date("2011-09-24");
console.log( new Date( doo.getTime() - doo.getTimezoneOffset() * -60000 ) );
您正在使用ISO日期字符串格式，根据此页，将导致使用UTC时区构造日期:
注意:使用date构造函数(和 日期。解析，它们是等效的)是强烈不鼓励的，因为 浏览器差异和不一致。支持RFC 2822格式 字符串只是按照惯例。对ISO 8601格式的支持有所不同 只有日期的字符串(例如:"1970-01-01")被视为UTC，而不是 当地。
如果文本格式不同，例如“Jan 01 1970”，那么(至少在我的机器上)它使用您的本地时区。
试着在这个帖子中添加我的2分(详细说明@paul-wintz的答案)。
在我看来，当日期构造函数接收到匹配ISO 8601格式(日期部分)的第一部分的字符串时，它会在UTC时区与0时间进行精确的日期转换。当该日期转换为当地时间时，可能会发生日期移位 如果午夜UTC是本地时区的较早日期。
new Date('2020-05-07')
Wed May 06 2020 20:00:00 GMT-0400 (Eastern Daylight Time)
如果日期字符串是任何其他“松散”格式(使用“/”或日期/月不填充为零)，则在本地时区创建日期，因此没有日期转移问题。
new Date('2020/05/07')
Thu May 07 2020 00:00:00 GMT-0400 (Eastern Daylight Time)
new Date('2020-5-07')
Thu May 07 2020 00:00:00 GMT-0400 (Eastern Daylight Time)
new Date('2020-5-7')
Thu May 07 2020 00:00:00 GMT-0400 (Eastern Daylight Time)
new Date('2020-05-7')
Thu May 07 2020 00:00:00 GMT-0400 (Eastern Daylight Time)
因此，如上所述，一个快速修复方法是将ISO格式的Date字符串中的“-”替换为“/”。
new Date('2020-05-07'.replace('-','/'))
Thu May 07 2020 00:00:00 GMT-0400 (Eastern Daylight Time)
