2

假设欧洲（英国）区域设置日期格式使用月份和年份的前几天，如下所示：

EEE, dd MMM yyyy

当我在toLocaleTimeString选项 weekday=short 中使用它时，我得到不一致的响应。日子在月后。

2013 年 9 月 27 日星期五 18:38:30 英国时间

但是，当我使用 weekday=long 时，它将与预期的日期格式一致。

2013 年 9 月 27 日星期五 18:38:30 英国时间

无论是使用短格式还是长格式，我都认为它应该是一致的并且有几个月前的几天。但是，事实并非如此，我不确定这是一种理想的行为还是我遗漏了一些观点？

这是 Chrome V29 中的 JavaScript 代码：

    var options = {
        hour: "2-digit",
        minute: "2-digit",
        second: "2-digit",
        year: "numeric",
        month: "short",
        day: "2-digit",
        hour12: false,
        timeZoneName: "short",

        weekday:"short"  //"long"
    }

    var date = new Date("Fri Sep 27 2013 13:38:30 GMT-0400");
    options.timeZone = 'America/New_York'
    console.log(date.toLocaleDateString("en-us",options))

    options.timeZone = 'Europe/London'
    console.log(date.toLocaleDateString("en-gb",options))

输出：

工作日=短

美国东部时间2013 年 9 月 27 日星期五 1:38:30 PM
英国时间 2013 年 9 月 27 日星期五 18:38:30

工作日=长

美国东部时间 2013 年 9 月 27 日
星期五下午 1:38:30 英国时间 2013 年 9 月 27 日星期五 18:38:30

预期的：

美国东部时间2013 年 9 月 27 日星期五 1:38:30 PM 2013 年 9 月 27 日
星期五 18:38:30 英国时间

4

1 回答 1

3

可以省略yearinoptions并正确获取日月格式，但是没有year值的日期字符串显然不好：

var options = {
    hour: "2-digit",
    minute: "2-digit",
    second: "2-digit",
    //year: "numeric",
    month: "short",
    day: "2-digit",
    hour12: false,
    timeZoneName: "short",

    weekday:"short"
}

回报：

Fri, Sep 27 1:38:30 PM ET
Fri 27 Sep 18:38:30 United Kingdom Time

所以这是一个临时的解决方法，直到我们找出这是怎么回事；您可以weekday单独设置 foren-GB以获得所需的结果，但最终会得到很长的工作日名称：

var options = {
        hour: "2-digit",
        minute: "2-digit",
        second: "2-digit",
        year: "numeric",
        month: "short",
        day: "2-digit",
        timeZoneName: "short",
        weekday: "short"
}

    var date = new Date("Fri Sep 27 2013 13:38:30 GMT-0400");
    options.timeZone = "America/New_York";
    console.log(date.toLocaleDateString("en-US",options));

    options.timeZone = "Europe/London";
    options.weekday = "long";
    console.log(date.toLocaleDateString("en-GB",options));

这将返回：

Fri, Sep 27, 2013 1:38:30 PM ET
Friday, 27 Sep 2013 18:38:30 United Kingdom Time

我仍在努力寻找造成这种情况的原因。这似乎不是 ICU 问题，它返回两个语言环境的预期值（参见 和 的结果en-GB）en-US。可能是要求使用工作日名称较短的格式并 year导致格式匹配器回退到en（使用E, MMM d y）。找出这是否是一个缺陷，需要更多的研究。如果我发现，我会在这里更新。

关于显式设置hour12. 考虑到 this 的默认值是locale-dependent，我认为最好也将其排除在外（正如您在 的输出时间格式中看到的那样，它无论如何都会被覆盖en-GB）。

于 2013-09-28T19:50:06.490 回答