likes
comments
collection
share

Date TIme Zone Unix 时区转换 | 附手写 Dayjs Luxon Moment.js 代码

作者站长头像
站长
· 阅读数 74

当涉及时间的处理时，你通常不用担心时区。因为你的电脑会在特定的本地时区中运行，所有的代码都将在特定的时区上一致的运行。

但是很不幸，如果你要跨区域处理时间，那就不得不处理时间的时区转换。

本文目的

本文将学习时区的关键概念，再学习时区的运行和计算逻辑，最后给出跨时区时间转换的具体实现。这些代码实现，将包括使用框架、手写实现，甚至源码的解读。你可以对比的参考这些不同的实现方式，选出适合你的一种。

关键概念 Date Time Zone/Offset Unix

以一个原生的Date类为例，他包含日期Date、时间Time以及时区Zone，还有对应的Unix时间戳。时区Zone在Date实例上，又经常以一个Offset偏移量的具体数值表示。

DateTime

Date实例的日期时间表示，包括年月日时分秒、时区等。格式可能是Thu Apr 20 2017 19:32:00 GMT+0800 (中国标准时间)，可能是2017-04-20T11:32:00.000Z，也可能是Friday, June 30, 2023 at GMT+01:00，还可能是Thu, 20 Apr 2017 03:32:00 GMT等。

  • 占位标记：f、F等
  • 获取RFC 822/RFC 1123/...标准格式的日期，如Thu Apr 20 2017 19:32:00 GMT+0800 (中国标准时间)：

    Date.prototype.toString()

  • 获取ISO 8601标准格式的日期，如2017-04-20T11:32:00.000Z：

    Date.prototype.toISOString()

  • 获取格林威治标准时间（GMT）（HTTP协议日期头部Date Header使用这种格式），如Thu, 20 Apr 2017 03:32:00 GMT：

    Date.prototype.toGMTString()

  • 获取特定时区与语言环境格式下的日期时间，如Friday, June 30, 2023 at GMT+01:00：

    Date.prototype.toLocaleString(locale, options) locale,options存在兼容问题

    const date = new Date();

// 请求参数包含星期，且该参数的值为长整型
const options = {
  weekday: "long",
  year: "numeric",
  month: "long",
  day: "numeric",
};

// 应用程序可能想要使用 UTC 时间，并使其可见
options.timeZone = "Europe/London";
options.timeZoneName = "longOffset";

console.log(date.toLocaleString("en-US", options));
// "Friday, June 30, 2023 at GMT+01:00"

Date

Date实例的日期部分，包括年月日。格式可能是1983-10-14，也可能是Fri, Oct 14, 1983等。

  • 占位标记：Y、M、D、L等
  • 获取RFC 822/RFC 1123/...标准格式的日期，如Fri Oct 14 1983：

    Date.prototype.toDateString()

  • 获取一个特定时区与语言环境格式下的日期，如Donnerstag, 20. Dezember 2012：

    Date.prototype.toLocaleDateString(locales, options) locale,options存在兼容问题

    const date = new Date(Date.UTC(2012, 11, 20, 3, 0, 0));

// request a weekday along with a long date
const options = {
  weekday: "long",
  year: "numeric",
  month: "long",
  day: "numeric",
};
console.log(date.toLocaleDateString("de-DE", options));
// "Donnerstag, 20. Dezember 2012"

// 应用程序可能想要使用 UTC 时间，并使其可见
options.timeZone = "UTC";
options.timeZoneName = "short";
console.log(date.toLocaleDateString("en-US", options));
// "Thursday, December 20, 2012, UTC"

Time

Date实例的时间部分，格式可能是19:32:00 GMT+0800 (中国标准时间)，也可能是7:31:24 PM，还可能是19:31:24等。

  • 占位标记：h、m、s、u、a、t等
  • 获取RFC 822/RFC 1123/...标准格式的日期，如19:32:00 GMT+0800 (中国标准时间)：

    Date.prototype.toTimeString()

  • 获取一个特定时区与语言环境格式下的日期，如7:31:24 PM：

    Date.prototype.toLocaleTimeString(locales, options) locale,options存在兼容问题

    new Date().toLocaleTimeString("en-US", {hour12: true})
// '7:31:24 PM'
new Date().toLocaleTimeString()
// '19:31:24'

Zone/Offset

Date实例的时区部分，格式可能是 +0800，也可能是Z，还可能是 UTC。

  • 占位标记：z、Z等
  • 获取协调世界时（UTC）相对于当前时区的时间差值，单位为分钟，如-480：

    Date.prototype.getTimezoneOffset()

Unix

Date实例的时间戳(timestamp)，格式可能是1688114469032(毫秒)，也可能是1688114469(秒)。

  • 占位标记：x、X等

UNIX时间戳，或称POSIX时间是UNIX或类UNIX系统使用的时间表示方式：从UTC1970年1月1日0时0分0秒起至现在的总秒数，不考虑闰秒。

时区关键概念

参考luxon文档原文

Bear with me here. Time zones are a pain in the ass. Luxon has lots of tools to deal with them, but there's no getting around the fact that they're complicated. The terminology for time zones and offsets isn't well-established. But let's try to impose some order:

  1. An offset is a difference between the local time and the UTC time, such as +5 (hours) or -12:30. They may be expressed directly in minutes, or in hours, or in a combination of minutes and hours. Here we'll use hours.
  2. A time zone is a set of rules, associated with a geographical location, that determines the local offset from UTC at any given time. The best way to identify a zone is by its IANA string, such as "America/New_York". That zone says something to the effect of "The offset is -5, except between March and November, when it's -4".
  3. A fixed-offset time zone is any time zone that never changes offsets, such as UTC. Luxon supports fixed-offset zones directly; they're specified like UTC+7, which you can interpret as "always with an offset of +7".
  4. A named offset is a time zone-specific name for an offset, such as Eastern Daylight Time. It expresses both the zone (America's EST roughly implies America/New_York) and the current offset (EST means -5). They are also confusing in that they overspecify the offset (e.g. for any given time it is unnecessary to specify EST vs EDT; it's always whichever one is right). They are also ambiguous (BST is both British Summer Time and Bangladesh Standard Time), unstandardized, and internationalized (what would a Frenchman call the US's EST?). For all these reasons, you should avoid them when specifying times programmatically. Luxon only supports their use in formatting.

Some subtleties:

  1. Multiple zones can have the same offset (think about the US's zones and their Canadian equivalents), though they might not have the same offset all the time, depending on when their DSTs are. Thus zones and offsets have a many-to-many relationship.
  2. Just because a time zone doesn't have a DST now doesn't mean it's fixed. Perhaps it had one in the past. Regardless, Luxon does not have first-class access to the list of rules, so it assumes any IANA-specified zone is not fixed and checks for its current offset programmatically.

If all this seems too terse, check out these articles. The terminology in them is subtly different but the concepts are the same:

Offset

TimeZone

FixedOffsetZone

NamedOffset

转载自:https://juejin.cn/post/7250375035634696251
评论
请登录