Question

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

EEE, dd MMM yyyy

当我在toLocaleTimeString中使用选项weekday = short时，我会得到不一致的回复。这个月过后的几天。

周五，2013年9月27日18:38:30英国时间

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

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))

输出：

with weekday = short

周五，2013年9月27日下午1:38:30 ET 星期五，2013年9月27日18:38:30英国时间

with weekday = long

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

预期：

周五，2013年9月27日下午1:38:30 ET 2013年9月27日星期五18:38:30英国时间

Answer 1

可以省略year中的options并正确获取日期格式，但如果没有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设置en-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的格式可能导致format matcher回退到en（使用E, MMM d y）。找出这是否是一个缺陷，需要更多的研究。如果我发现，我会在这里更新。

关于明确设置hour12的一个小注释。考虑到默认值为locale-dependent，我认为最好不要这样做（正如您在en-GB的输出时间格式中所看到的那样，它被覆盖了。）

“Intl.toLocaleTimeString”对于英文语言环境的短格式和长格式的行为不一致

1 个答案: