我已经花了一天的时间在这个问题上,深入到源代码中,这看起来是一个可怕的javascript moment.tz库的问题:
每当我传入时区标识符"Etc/GMTtime- value“时,返回的moment.tz对象将返回我认为是格式(”Z“)值的值,因为它被乘以-1。
示例:
var pacificTime = moment.tz("2016-09-29 21:00:00","America/Los_Angeles");
pacificTime.format("YYYY-MM-DD HH:mm:ss Z z");输出:"2016-09-29 21:00:00-07:00 PDT“
这里一切都如期而至。
现在,使用相同的时区(GMT-7):
var GMT_minus_7 = moment.tz("2016-09-29 21:00:00","Etc/GMT-7");
GMT_minus_7.format("YYYY-MM-DD HH:mm:ss Z z");输出:"2016-09-29 21:00:00 +07:00 GMT-7“
大胆的面值总是我认为应该是的负值:传入"Etc/GMT+5“返回一个"-5:00”值。
这让我感到头疼,因为我正在使用的web页面有一个包含日期/时间记录的整数"GMT偏移量“值,我只需将其转换为"Etc/GMT”+ offset_value,然后传递到moment.tz进行时区转换。然后,我需要对值进行进一步的操作(添加天数,显示"Z“格式的值,等等)。但这一问题阻碍了进一步的工作。
这是moment.tz解析"Etc/GMT“时区值的一个缺陷,还是我忽略了时区格式的一些基本内容?
发布于 2016-09-29 23:18:40
IANA数据库中的标识符(如Etc/GMT-7 )故意倒置它们的偏移量。这是这种标识符样式设计的一部分。见维基百科上关于这个的笔记和在tz数据库源本身中。。(基本上,这是因为在某些环境中需要向后兼容较旧的POSIX标准。)
但是,对于Moment.js,如果使用固定时区偏移量,则根本不需要使用这些偏移量。实际上,您根本不需要时区扩展。
// the parseZone method will retain the offset provided
var a = moment.parseZone("2016-09-29 21:00:00 -07:00");
// or, you can set the offset explicitly like this:
var b = moment.utc("2016-09-29 21:00:00").utcOffset("-07:00", true);
// or like this if you prefer:
var c = moment.utc("2016-09-29 21:00:00").utcOffset(-7, true);对于b和c,请注意,需要true参数来保留给定的本地时间。还请注意,我最初使用moment.utc(...)来解析字符串。它也只适用于moment(...),但是本地时区中的DST转换可能会干扰临时值。
另外,确保您认识到America/Los_Angeles在-8到-7之间交替,这取决于DST是否有效。这就是为什么你需要时刻时区来提供关于何时在偏移量之间切换的规则。
https://stackoverflow.com/questions/39779597
复制相似问题