我确实让 fullcalendar 正常初始化。所以它代表当前日期。 (Midnight->midnight, 1day, 1h slots)
我从其他一些数据源获取带有时间戳的数据。格式为“YYYY-MM-DD HH:mm”(以字符串形式传输,无时区信息)
所以我将该字符串转换为 moment 对象并针对 fullcalendar.start 和 .end 进行测试以查看它是否在其中。
moment("2016-04-07 00:00") == $('#calendar').fullCalendar('getView').end
这通过以下命令导致false
$('#calendar').fullCalendar('getView').end.format("YYYY-MM-DD HH:mm")
返回
"2016-04-07 00:00"
我也试过比较diff
moment("2016-04-07 00:00").diff( $('#calendar').fullCalendar('getView').end,"minutes")
返回
120
Chrome Dev Tools 中对 calendars.end 对象的一些研究表明它在内部表示为
2016-04-07 02:00 GMT+0200
这对我来说很奇怪。我在格林威治标准时间前 2 小时的时区。所以它应该正确地说 2016-04-07 00:00 GMT+0200,不是吗? 这也解释了为什么上面的 diff 测试结果是 120 分钟。
有人可以帮忙吗?我不知道转换问题从何而来。我只使用没有时区信息的日期。如上所述,fullcalendar 初始化时没有 gotodate 信息,并显示从 00:00 到 00:00 的时间栏。那么为什么会有这2h的差异呢?
最佳答案
非常感谢。我现在确实更了解事情了。 我试图比较的一些日期是“现在”。我得到了“现在”
var n = moment()
原来是一个日期时间,包括我的时区。
例如moment().format() 结果为“2016-04-07 00:00 GMT+0200”,我现在明白这是怎么回事了,除了与完整 calendar.end 的比较是 true 但它为 false,因为“2016-04-07 00:00 GMT+0200”在 UTC 时为“2016-04-06 22:00”。
作为
moment.utc()
不起作用,我知道最终使用了
moment.utc(moment().format('YYYY-MM-DD HH:mm'))
现在这似乎可以工作了,因为这将我的本地时间视为 UTC 的“数字同一时间”。因此与 fullcalendar 在内部处理时间(模糊区域时刻)的方式相匹配。
谢谢
关于javascript - 与 UTC 和本地日期的全日历混淆,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/36500776/