Question

我已经在这上面敲了一天，进入了源代码，这个看起来是一个很棒的javascript moment.tz库的问题：

每当我传入＆＃34; Etc / GMT 时间值＆＃34;的时区标识符时，返回的moment.tz对象将返回我认为的格式（＆＃34; Z＆＃34;）值乘以-1。

示例：

var pacificTime = moment.tz("2016-09-29 21:00:00","America/Los_Angeles");
pacificTime.format("YYYY-MM-DD HH:mm:ss Z z");

输出：＆＃34; 2016-09-29 21:00:00 -07：00 PDT＆＃34;

一切都如预期的那样。

现在，使用相同的时区（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");

输出：＆＃34; 2016-09-29 21:00:00 +07：00 GMT-7＆＃34;

大胆的价值始终是我认为应该是的负面价值：传入＆＃34; Etc / GMT + 5＆＃34;返回＆＃34; -5：00＆＃34;值。

这让我很头疼，因为我正在使用的网页上有日期/时间记录的记录是整数＆＃34; GMT偏移＆＃34;我简单地变成了＃34; Etc / GMT＆＃34; + offset_value 并传入moment.tz进行时区转换。然后，我需要对值进行进一步操作（添加天数，显示＆＃34; Z＆＃34;格式化值等），但此问题阻碍了进一步的工作。

这是一个缺陷，有时会解析＆＃34; Etc / GMT＆＃34;时区值，还是我遗漏了一些关于时区格式的基本信息？

Answer 1

IANA数据库中的标识符（例如Etc/GMT-7）的偏移量有意。这是这种标识符设计的一部分。请参阅the note in Wikipedia on this和in the tz database source itself。（基本上，它源于在某些环境中需要向后兼容旧的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是否生效。这就是为什么你需要时刻时区来提供何时在偏移之间切换的规则。

moment.tz问题设置＆＃34; Etc / GMT [+ | - ] HH：MM＆＃34;时区

1 个答案: