Intl.DateTimeFormat给出了1847年或以下年份的奇怪结果 [英] Intl.DateTimeFormat gives strange result from year 1847 or below

问题描述

为什么我选择1848年以下的年份，这种格式的结果是 5月10 ？

<我觉得这可能与时区有关？如果是这样，我将如何避免这种情况，因为我将根据如下所示的ISO日期字符串（没有时间）创建日期对象： YYYY-MM-DD 。

（已在Chrome 59上测试）

  const workingDate = Intl.DateTimeFormat（'en-GB'）。format（new Date（'Fri May 11 1848 01:00:00 GMT + 0100（BST）'））; const notWorkingDate = Intl.DateTimeFormat（ 'en-GB'）。format（new Date（'Fri May 11 1847 01:00:00 GMT + 0100（BST）'））; console.log（workingDate）; console.log（notWorkingDate）;  

上面的日期字符串来自例如新日期（'1847-05-11'）（我处于BST时区）

解决方案

此测试是在Chrome 53中进行的。

我已向 DateTimeFormat 检查日期的其他字段：

  options = {
 year：'numeric'，month： 'numeric'，日期：'numeric'，
小时：'numeric'，分钟：'numeric'，秒：'numeric'，
 hour12：false，timeZoneName：'long'
} ; 
 var workingDate = Intl.DateTimeFormat（'en-GB'，options）.format（new Date（'Fri May 11 1848 01:00:00 GMT + 0100（BST）'））; 
 var notWorkingDate = Intl.DateTimeFormat（'en-GB'，options）.format（new Date（'Fri May 11 1847 01:00:00 GMT + 0100（BST）'））; 
  

结果是：

  workingDate：10/05/1848，20:53:32 GMT-03：06：28 
 notWorkingDate：10/05/1847，20:53:32 GMT-03：06： 28 
  

在1900年之前，大多数地方都没有基于UTC的标准补偿（实际上，每个国家都采用了在不同的年份），因此在1900年之前，您总是会得到这些奇怪的结果。实际上，如 Matt在评论，UTC于1972年实施，在此之前，大多数区域都被定义为偏离GMT的时间。无论如何，对于非常古老的日期，尤其是在1900年之前，您可能会期望像上述的偏移量。

。

在这种情况下，它将获得系统的相应偏移量默认时区（ America / Sao_Paulo ）：1914年之前是 -03：06：28 。

在伦敦（我假设这是您的默认时区），在1​​847年12月1日之前，偏移量为 -00：01：15 （由lat / lon计算） ，请再次参见 Matt的评论更多详细信息），然后将其更改为 +00：00 （这就是为什么它适用于1848年日期的原因）。

我已经进行了一次测试，将时区设置为欧洲/伦敦：

  options = {
年：数字，月：数字， day：'numeric'，
 hour：'numeric'，minutes：'numeric'，second：'numeric'，
 hour12：false，timeZoneName：'long'，timeZone：'Europe / London'
}; 
 var workingDate = Intl.DateTimeFormat（'en-GB'，options）.format（new Date（'Fri May 11 1848 01:00:00 GMT + 0100（BST）'））; 
 var notWorkingDate = Intl.DateTimeFormat（'en-GB'，options）.format（new Date（'Fri May 11 1847 01:00:00 GMT + 0100（BST）'））; 
  

结果是：

11/05/1848，00:00:00 GMT

10/05/1847，23:58:45 GMT-00：01：15

其中确认在1847年12月之前，日期具有不同的偏移量。

---

一种解决方法，就是将日期视为UTC：

  options = {
 timeZone：'UTC'
}; 
 var workingDate = Intl.DateTimeFormat（'en-GB'，options）.format（new Date（'Fri May 11 1848 01:00:00 GMT + 0100（BST）'））; 
 var notWorkingDate = Intl.DateTimeFormat（'en-GB'，options）.format（new Date（'Fri May 11 1847 01:00:00 GMT + 0100（BST）'））; 
  

值将为：

11/05/1848

11/05/1847

Why is it that if I choose a year below 1848, the result of this format is May 10?

I have a feeling this could be about time zones? If so how can I avoid this, given that I will be creating a date object from an ISO date string (without time) like this: YYYY-MM-DD.

(Tested on Chrome 59)

const workingDate = Intl.DateTimeFormat('en-GB').format(new Date('Fri May 11  1848 01:00:00 GMT+0100 (BST)'));
const notWorkingDate = Intl.DateTimeFormat('en-GB').format(new Date('Fri May 11  1847 01:00:00 GMT+0100 (BST)'));

console.log(workingDate);
console.log(notWorkingDate);

Date strings above are from e.g. new Date('1847-05-11') (I'm in BST time zone)

解决方案

This test was made in Chrome 53.

I've added some options to DateTimeFormat to check the other fields of the date:

options = {
    year: 'numeric', month: 'numeric', day: 'numeric',
    hour: 'numeric', minute: 'numeric', second: 'numeric',
    hour12: false, timeZoneName: 'long'
};
var workingDate = Intl.DateTimeFormat('en-GB', options).format(new Date('Fri May 11  1848 01:00:00 GMT+0100 (BST)'));
var notWorkingDate = Intl.DateTimeFormat('en-GB', options).format(new Date('Fri May 11  1847 01:00:00 GMT+0100 (BST)'));

The result was:

workingDate: 10/05/1848, 20:53:32 GMT-03:06:28
notWorkingDate: 10/05/1847, 20:53:32 GMT-03:06:28

Most places didn't have standardized UTC-based offsets before 1900 (actually, each country adopted it in a different year), so before 1900 you always get those strange results. Actually, as Matt explained in the comments, UTC was implemented in 1972 and before that most zones were defined as offsets from GMT. Anyway, for very ancient dates, specially before 1900, you might expect offsets like the above.

In this case, it's getting the corresponding offset for my system's default timezone (America/Sao_Paulo): before 1914 it was -03:06:28.

In London (which I'm assuming it's your default timezone), before 1847-12-01 the offset was -00:01:15 (calculated by lat/lon, see again Matt's comment for more details), and after that it was changed to +00:00 (that' why it works for dates in 1848).

I've made a test setting the timezone to Europe/London:

options = {
    year: 'numeric', month: 'numeric', day: 'numeric',
    hour: 'numeric', minute: 'numeric', second: 'numeric',
    hour12: false, timeZoneName: 'long', timeZone: 'Europe/London'
};
var workingDate = Intl.DateTimeFormat('en-GB', options).format(new Date('Fri May 11  1848 01:00:00 GMT+0100 (BST)'));
var notWorkingDate = Intl.DateTimeFormat('en-GB', options).format(new Date('Fri May 11  1847 01:00:00 GMT+0100 (BST)'));

The result was:

11/05/1848, 00:00:00 GMT
10/05/1847, 23:58:45 GMT-00:01:15

Which confirms that before December/1847, dates had a different offset.

---

One way to fix it, is to consider the date as UTC:

options = {
    timeZone: 'UTC'
};
var workingDate = Intl.DateTimeFormat('en-GB', options).format(new Date('Fri May 11  1848 01:00:00 GMT+0100 (BST)'));
var notWorkingDate = Intl.DateTimeFormat('en-GB', options).format(new Date('Fri May 11  1847 01:00:00 GMT+0100 (BST)'));

The values will be:

11/05/1848
11/05/1847

这篇关于Intl.DateTimeFormat给出了1847年或以下年份的奇怪结果的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！