关于javascript:moment.tz问题,设置” Etc / GMT [|-] HH:MM”时区

moment.tz issue with setting a “Etc/GMT[+|-]HH:MM” timezone

我已经花了整整一天的时间来研究这个问题,进入了源代码,这似乎是一个很棒的javascript moment.tz库的问题:

每当我传入时区标识符" Etc / GMTtime-value "时,返回的moment.tz对象都会返回我认为是format(" Z ")值的值,因为它乘以-1。

示例:

1
2
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):

1
2
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 "值。

这让我头疼,因为我正在使用的网页上有记录的日期/时间记录了一个整数" GMT offset "值,我将其简单地变成了"" Etc / GMT " offset_value",传递到moment.tz以进行时区转换。然后,我需要对该值进行进一步的操作(添加天数,显示" Z "格式的值等),但是此问题妨碍了进一步的工作。

moment.tz解析\\ Etc / GMT \\时区值是否是缺陷,还是我缺少有关时区格式的基本知识?


IANA数据库中的标识符(例如Etc/GMT-7)有意地反转了其偏移量。这是这种样式的标识符的设计的一部分。请参阅Wikipedia中的注释以及tz数据库源本身。 (基本上,这是因为在某些环境中需要与较早的POSIX标准向后兼容。)

但是,对于Moment.js,如果您使用固定的时区偏移量,则根本不需要使用它们。实际上,您根本不需要时区扩展。

1
2
3
4
5
6
7
8
// 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);

对于bc,请注意,必须使用true参数来保留给定的本地时间。另请注意,我使用moment.utc(...)初始分析了字符串。 moment(...)也可以使用,但是本地时区中的DST过渡可能会干扰中间值。

此外,请确保您认识到America/Los_Angeles在DST是否有效的情况下在-8和-7之间交替。这就是为什么您需要使用矩时区来提供何时在偏移之间进行切换的规则的原因。