描述
ZonedDateTime 在确切时间和挂钟时间之间充当桥梁:它同时表示历史上的一个瞬间(类似于 Temporal.Instant)和一个本地的挂钟时间(类似于 Temporal.PlainDateTime)。它通过存储瞬间、时区和日历系统来实现这一点。时区用于在瞬间和本地时间之间进行转换,而日历系统用于解释本地时间。
ZonedDateTime 是唯一一个具有时区感知的 Temporal 类。时区的加入使得 ZonedDateTime 对象与 Temporal.PlainDateTime 对象在行为上有重要区别。也就是说,你不能再假设“1 分钟后的时间”每天都是相同的,或者一天有 24 小时。在最坏的情况下,本地日历中可能会整整缺少一天。下面,我们简要介绍时区和偏移量,以及它们如何影响 UTC 时间和本地时间之间的转换。
时区和偏移量
JavaScript 中的所有时间都有一个黄金标准:UTC 时间,它随着物理时间的推移而连续、均匀地递增。相比之下,用户更关心他们的本地时间,也就是他们在日历和时钟上读取的时间。UTC 时间和本地时间之间的转换过程涉及到时区偏移量,其计算公式为:
local time = UTC time + offset
例如,如果 UTC 时间是 1970-01-01T00:00:00,偏移量是“-05:00”,那么本地时间就是:
1970-01-01T00:00:00 + -05:00 = 1969-12-31T19:00:00
通过给这个本地时间加上偏移量后缀,将其表示为“1969-12-31T19:00:00-05:00”,它就可以被明确地理解为历史上的一个瞬间。
要知道偏移量,我们需要两部分信息:时区和瞬间。时区是地球上的一个区域,在任何时候都使用相同的偏移量。在同一时区内的两个时钟将始终同时显示相同的时间,但偏移量不一定是恒定的:也就是说,这些时钟的时间可能会突然改变。这通常发生在夏令时转换期间,此时偏移量会改变一小时,每年发生两次。由于政治原因,偏移量也可能永久改变,例如一个国家更换时区。
时区存储在 IANA 时区数据库中。每个 IANA 时区都有:
- 一个唯一标识该时区的主时区标识符。它通常指向一个以城市为中心的地理区域(例如
Europe/Paris或Africa/Kampala),但也可以表示单一偏移量的时区,如UTC(始终为+00:00偏移量)或Etc/GMT+5(由于历史原因,这是一个负偏移量-05:00)。由于历史原因,UTC 时区的主名称是UTC,尽管在 IANA 中是Etc/UTC。 - 一个以表格形式呈现的时区定义,将 UTC 日期/时间范围(包括未来范围)映射到特定的偏移量。
- 零个或多个非主时区标识符,它们是主时区标识符的别名。这些通常是不再使用的历史名称,但为了兼容性而保留。详情见下文。
作为输入,命名标识符不区分大小写进行匹配。在内部,它们以其首选大小写形式存储,并且非主标识符将不会被转换为主标识符。
注意:在设置时区名称时,你很少会想把它设置为 "UTC"。ZonedDateTime 旨在向用户显示,但没有人生活在“UTC”时区。如果你在构造时不知道时区,但知道挂钟时间,请使用 Temporal.PlainDateTime。如果你知道确切的瞬间,请使用 Temporal.Instant。
当 Temporal API 接受一个时区标识符时,除了主时区标识符和非主时区标识符外,它还接受一个偏移时区标识符,其形式与偏移量相同,但不允许亚分钟精度。例如,+05:30、-08、+0600 都是有效的偏移标识符。在内部,偏移标识符以 ±HH:mm 形式存储。
注意:如果可以使用命名时区,请避免使用偏移标识符。即使一个地区一直使用单一偏移量,也最好使用命名标识符,以防将来偏移量发生政治变化。
如果一个地区使用(或曾经使用)多个偏移量,那么使用其命名时区就更加重要。这是因为 Temporal.ZonedDateTime 可以使用像 add 或 with 这样的方法来创建在不同瞬间的新实例。如果这些派生实例对应于使用不同偏移量的瞬间(例如,在夏令时转换之后),那么你的计算将得到不正确的本地时间。使用命名时区可以确保本地日期和时间始终针对该瞬间的正确偏移量进行调整。
为方便起见,在向 Temporal API(如 Temporal.ZonedDateTime.prototype.withTimeZone() 和 Temporal.ZonedDateTime.from() 的 timeZoneId 选项)提供时区标识符时,你还可以使用其他几种形式:
- 作为另一个
ZonedDateTime实例,将使用其timeZoneId。 - 作为带有RFC 9557 字符串的时区注解,将使用其时区标识符。
- 作为包含偏移量的 ISO 8601 / RFC 3339 字符串,其偏移量将被用作偏移标识符;或者,如果使用
Z,则使用"UTC"时区。通常不建议使用这种方法,因为如上所述,偏移标识符缺乏在偏移量转换(如夏令时开始或结束)时安全派生其他Temporal.ZonedDateTime实例的能力。相反,可以考虑只使用Temporal.Instant或获取用户的实际命名时区。
IANA 时区数据库会不时更改,通常是为了应对政治变化而增加新的时区。然而,在极少数情况下,IANA 时区标识符会为了匹配城市名称的更新英文翻译或更新过时的命名约定而重命名。例如,以下是一些值得注意的名称变更:
| 当前 IANA 主标识符 | 旧的、现为非主的标识符 |
|---|---|
America/Argentina/Buenos_Aires |
America/Buenos_Aires |
Asia/Kolkata |
Asia/Calcutta |
Asia/Ho_Chi_Minh |
Asia/Saigon |
Europe/Kyiv |
Europe/Kiev |
从历史上看,这些重命名给程序员带来了问题,因为 Unicode CLDR 数据库(浏览器依赖其提供时区标识符和数据的库)出于稳定性原因而没有跟随 IANA 的重命名。因此,一些浏览器(如 Chrome 和 Safari)报告了 CLDR 的过时标识符,而其他浏览器(如 Firefox)则覆盖了 CLDR 的默认设置,报告了最新的主标识符。
随着 Temporal 的引入,这种行为现在更加标准化:
- CLDR 数据现在包含一个
"_iana"属性,如果旧的、稳定的标识符已被重命名,该属性会指示最新的标识符。浏览器可以使用这个新属性向调用者提供最新的标识符。 - 程序员提供的时区标识符永远不会被别名替换。例如,如果调用者向
Temporal.ZonedDateTime.from()提供Asia/Calcutta或Asia/Kolkata作为标识符输入,那么在结果实例的timeZoneId中会返回相同的标识符。请注意,输出的大小写会根据 IANA 进行规范化,因此输入ASIA/calCuTTa会生成一个timeZoneId为Asia/Calcutta的输出。 - 当不是由调用者提供,而是从系统本身获取时区标识符时(例如,使用
Temporal.Now.timeZoneId()),所有浏览器都会返回现代标识符。对于城市重命名,这些系统提供的标识符 API 会有两年的延迟才会暴露新名称,从而给其他组件(如 Node 服务器)时间来更新其 IANA 数据库的副本以识别新名称。
请注意,主标识符的归属会保留国家代码:例如,IANA 数据库将 Atlantic/Reykjavik 记录为 Africa/Abidjan 的别名,但由于它们对应不同的国家(分别是冰岛和科特迪瓦),因此它们被视为不同的主标识符。
这种标准化也适用于 Temporal 之外。例如,由 Intl.DateTimeFormat.prototype.resolvedOptions() 返回的 timeZone 选项也不会被别名替换,尽管在 Temporal 标准化之前,浏览器传统上会规范化这些标识符。另一方面,Intl.Locale.prototype.getTimeZones() 和 Intl.supportedValuesOf()(timeZone 选项)将返回最新的标识符,而一些浏览器过去会返回旧的非主标识符。
RFC 9557 格式
ZonedDateTime 对象可以使用 RFC 9557 格式进行序列化和解析,该格式是 ISO 8601 / RFC 3339 格式的扩展。字符串具有以下形式(空格仅为可读性,不应出现在实际字符串中):
YYYY-MM-DD T HH:mm:ss.sssssssss Z/±HH:mm [time_zone_id] [u-ca=calendar_id]
YYYY-
一个四位数,或者一个带
+或-号的六位数。 MM-
一个从
01到12的两位数。 DD-
一个从
01到31的两位数。YYYY、MM和DD部分可以用-分隔或不用。 T可选-
日期时间分隔符,可以是
T、t或空格。当且仅当HH存在时出现。 HH可选-
一个从
00到23的两位数。默认为00。 mm可选-
一个从
00到59的两位数。默认为00。 ss.sssssssss可选-
一个从
00到59的两位数。可以选择后跟.或,和一到九位数字。默认为00。HH、mm和ss部分可以用:分隔或不用。你可以只省略ss或同时省略ss和mm,因此时间可以有三种形式:HH、HH:mm或HH:mm:ss.sssssssss。 Z/±HH:mm可选-
UTC 指示符
Z或z,或以+或-后跟与时间部分相同格式的 UTC 偏移量。请注意,亚分钟精度(:ss.sssssssss)可能不被其他系统支持,并且虽然接受但不输出。如果省略,则从时区标识符推导偏移量。如果存在,则时间也必须提供。Z与+00:00不同:前者表示无论时区标识符如何,时间都以 UTC 形式给出,而后者表示时间以本地时间给出,恰好是 UTC+0,并将通过offset选项与时区标识符进行验证。 [time_zone_id]-
将
time_zone_id替换为上述描述的时区标识符(命名或偏移)。可以通过在标识符前加!来添加关键标志:例如[!America/New_York]。这个标志通常告诉其他系统,如果它们不支持它,就不能忽略它。请注意,对于Temporal.ZonedDateTime.from()来说,这是必需的:省略它会导致RangeError。如果你想解析没有时区标识符注解的 ISO 8601 / RFC 3339 字符串,请改用Temporal.Instant.from()。 [u-ca=calendar_id]可选-
将
calendar_id替换为要使用的日历。有关常用支持的日历类型列表,请参阅Intl.supportedValuesOf()。默认为[u-ca=iso8601]。可以通过在键前加!来添加关键标志:例如[!u-ca=iso8601]。这个标志通常告诉其他系统,如果它们不支持它,就不能忽略它。如果注解包含两个或多个日历注解且其中一个是关键的,Temporal解析器将抛出错误。请注意,YYYY-MM-DD始终被解释为 ISO 8601 日历日期,然后转换为指定的日历。
作为输入,[key=value] 格式的其他注解将被忽略,并且它们不能有关键标志。
在序列化时,你可以配置小数秒位数,是否显示偏移量/时区 ID/日历 ID,以及是否为注解添加关键标志。
本地时间到 UTC 时间转换的模糊性和间隙
给定一个时区,从 UTC 到本地时间的转换是直接的:你首先使用时区名称和瞬间获取偏移量,然后将偏移量添加到瞬间。反过来则不成立:从本地时间到 UTC 时间的转换,如果没有明确的偏移量,是模糊的,因为一个本地时间可以对应零个、一个或多个 UTC 时间。考虑最常见的原因:夏令时转换。以纽约为例。其标准偏移量是 UTC-5,但在夏令时期间,所有时钟都向前拨快一小时,因此偏移量变为 UTC-4。在美国,转换发生在本地时间凌晨 2:00,所以考虑这两个转换日:
| UTC 时间 | 纽约时间 |
|---|---|
| 2024-03-10T06:58:00Z | 2024-03-10T01:58:00-05:00 |
| 2024-03-10T06:59:00Z | 2024-03-10T01:59:00-05:00 |
| 2024-03-10T07:00:00Z | 2024-03-10T03:00:00-04:00 |
| --- | --- |
| 2024-11-03T05:58:00Z | 2024-11-03T01:58:00-04:00 |
| 2024-11-03T05:59:00Z | 2024-11-03T01:59:00-04:00 |
| 2024-11-03T06:00:00Z | 2024-11-03T01:00:00-05:00 |
如你所见,在三月份,本地时间消失了一小时,而在十一月份,我们有两个小时的挂钟时间是相同的。假设我们存储了一个 PlainDateTime,表示“2024-03-10T02:05:00”,并且我们想在 America/New_York 时区解释它,那么将没有时间与之对应;而一个表示“2024-11-03T01:05:00”的 PlainDateTime 可以对应两个不同的瞬间。
当从本地时间构造一个 ZonedDateTime 时(使用 Temporal.ZonedDateTime.from()、Temporal.ZonedDateTime.prototype.with()、Temporal.PlainDateTime.prototype.toZonedDateTime()),对于模糊性和间隙的行为可以通过 disambiguation 选项进行配置:
earlier-
如果存在两个可能的瞬间,则选择较早的一个。如果存在间隙,则按间隙时长向后退。
later-
如果存在两个可能的瞬间,则选择较晚的一个。如果存在间隙,则按间隙时长向前进。
compatible(默认值)-
与
Date的行为相同:对间隙使用later,对模糊情况使用earlier。 reject-
当出现模糊性或间隙时,抛出
RangeError。
在以下几种情况下,构造 ZonedDateTime 时没有模糊性:
- 如果时间通过
Z偏移量以 UTC 指定。 - 如果明确提供了偏移量并被使用(见下文)。
偏移量模糊性
我们已经展示了在不提供明确偏移量的情况下,在时区中解释本地时间可能如何产生模糊性。但是,如果你提供了明确的偏移量,那么就会出现另一个冲突:指定的偏移量与根据时区和本地时间计算出的偏移量之间的冲突。这是一个不可避免的现实问题:如果你存储一个未来的时间,并附带一个预期的偏移量,那么在那个时间到来之前,时区定义可能由于政治原因而改变。例如,假设在 2018 年,我们设置了一个提醒时间为 2019-12-23T12:00:00-02:00[America/Sao_Paulo](这是一个夏令时时间;巴西在南半球,所以它在十月进入夏令时,在二月退出)。但在那个时间到来之前,在 2019 年初,巴西决定停止实行夏令时,所以实际的偏移量变成了 -03:00。那么,提醒现在应该仍然在中午响起(保持本地时间),还是应该在上午 11:00 响起(保持确切时间)?
当使用 Temporal.ZonedDateTime.from() 构造 ZonedDateTime 或使用 with() 方法更新它时,偏移量模糊性的行为可以通过 offset 选项进行配置:
use-
使用偏移量来计算确切时间。这个选项在确定字符串所代表的瞬间时“使用”了偏移量,这将是我们存储时间时最初计算的那个瞬间,即使那个瞬间的偏移量已经改变了。时区标识符仍然用于推断(可能已更新的)偏移量,并使用该偏移量将确切时间转换为本地时间。
ignore-
使用时区标识符重新计算偏移量,忽略字符串中指定的偏移量。这个选项保持了与我们存储时间时最初计算的相同的本地时间,但可能对应于一个不同的瞬间。请注意,这个选项可能会导致与上面展示的相同的本地时间解释模糊性,该模糊性将使用
disambiguation选项来解决。 reject-
当偏移量和时区标识符之间存在冲突时,抛出
RangeError。这是Temporal.ZonedDateTime.from()的默认行为。 prefer-
如果偏移量有效,则使用它,否则从时区标识符计算偏移量。这是
Temporal.ZonedDateTime.prototype.with()的默认行为(详情请参见该方法)。这与ignore不同,因为在本地时间模糊的情况下,偏移量用于解决它,而不是disambiguation选项。
请注意,Z 偏移量不等同于 +00:00。根据 RFC 9557,Z 偏移量表示“UTC 时间已知,但到本地时间的偏移量未知”。当时间字符串使用 Z 偏移量时,offset 选项将被忽略,偏移量将从时区 ID 中推导出来。另一方面,+00:00 偏移量被解释为恰好与 UTC 匹配的本地时间偏移量,并会根据时区 ID 进行验证。
注意:尽管 Temporal.Instant.from() 也接受一个相同形式的 RFC 9557 字符串,但不存在模糊性,因为它总是忽略时区标识符,只读取偏移量。
构造函数
Temporal.ZonedDateTime()实验性-
通过直接提供底层数据创建一个新的
Temporal.ZonedDateTime对象。
静态方法
Temporal.ZonedDateTime.compare()实验性-
返回一个数字(-1、0 或 1),指示第一个日期时间是在第二个日期时间之前、与之相同还是在其之后。等同于比较两个日期时间的
epochNanoseconds。 Temporal.ZonedDateTime.from()实验性-
从另一个
Temporal.ZonedDateTime对象、一个具有日期、时间和时区属性的对象,或一个 RFC 9557 字符串创建一个新的Temporal.ZonedDateTime对象。
实例属性
这些属性定义在 Temporal.ZonedDateTime.prototype 上,并由所有 Temporal.ZonedDateTime 实例共享。
Temporal.ZonedDateTime.prototype.calendarId实验性-
返回一个字符串,表示用于解释内部 ISO 8601 日期的日历。
Temporal.ZonedDateTime.prototype.constructor-
创建实例对象的构造函数。对于
Temporal.ZonedDateTime实例,初始值为Temporal.ZonedDateTime()构造函数。 Temporal.ZonedDateTime.prototype.day实验性-
返回一个正整数,表示此日期在本月中的基于 1 的日期索引,这与你在日历上看到的日期数字相同。依赖于日历。通常从 1 开始并且是连续的,但并非总是如此。
Temporal.ZonedDateTime.prototype.dayOfWeek实验性-
返回一个正整数,表示此日期在本周中的基于 1 的日期索引。一周中的天数从
1顺序编号到daysInWeek,每个数字映射到其名称。依赖于日历。在日历中,1 通常代表星期一,即使使用该日历的区域设置可能认为另一天为一周的第一天(参见Intl.Locale.prototype.getWeekInfo())。 Temporal.ZonedDateTime.prototype.dayOfYear实验性-
返回一个正整数,表示此日期在本年中的基于 1 的日期索引。今年的第一天是
1,最后一天是daysInYear。依赖于日历。 Temporal.ZonedDateTime.prototype.daysInMonth实验性-
返回一个正整数,表示此日期所在月份的天数。依赖于日历。
Temporal.ZonedDateTime.prototype.daysInWeek实验性-
返回一个正整数,表示此日期所在星期中的天数。依赖于日历。对于 ISO 8601 日历,这总是 7,但在其他日历系统中,每周可能不同。
Temporal.ZonedDateTime.prototype.daysInYear实验性-
返回一个正整数,表示此日期所在年份的天数。依赖于日历。对于 ISO 8601 日历,这是 365,闰年是 366。
Temporal.ZonedDateTime.prototype.epochMilliseconds实验性-
返回一个整数,表示从 Unix 纪元(1970 年 1 月 1 日午夜开始,UTC)到此瞬间经过的毫秒数。等同于将
epochNanoseconds除以1e6并向下取整。 Temporal.ZonedDateTime.prototype.epochNanoseconds实验性-
返回一个
BigInt,表示从 Unix 纪元(1970 年 1 月 1 日午夜开始,UTC)到此瞬间经过的纳秒数。 Temporal.ZonedDateTime.prototype.era实验性-
返回一个日历特定的小写字符串,表示此日期的纪元,如果日历不使用纪元(例如 ISO 8601),则返回
undefined。era和eraYear一起唯一地标识日历中的一年,就像year一样。依赖于日历。对于格里高利历,它是"gregory"或"gregory-inverse"。 Temporal.ZonedDateTime.prototype.eraYear实验性-
返回一个非负整数,表示此日期在纪元内的年份,如果日历不使用纪元(例如 ISO 8601),则返回
undefined。年份索引通常从 1(更常见)或 0 开始,一个纪元内的年份可以随时间减少(例如格里高利历的公元前)。era和eraYear一起唯一地标识日历中的一年,就像year一样。依赖于日历。 Temporal.ZonedDateTime.prototype.hour实验性-
返回一个从 0 到 23 的整数,表示此时间的小时部分。
Temporal.ZonedDateTime.prototype.hoursInDay实验性-
返回一个正整数,表示此日期所在时区中的天数中的小时数。在偏移量变化(如夏令时)的情况下,它可能大于或小于 24。
Temporal.ZonedDateTime.prototype.inLeapYear实验性-
返回一个布尔值,指示此日期是否在闰年。闰年是指比平年有更多天数(由于闰日或闰月)的年份。依赖于日历。
Temporal.ZonedDateTime.prototype.microsecond实验性-
返回一个从 0 到 999 的整数,表示此时间的微秒(10-6 秒)部分。
Temporal.ZonedDateTime.prototype.millisecond实验性-
返回一个从 0 到 999 的整数,表示此时间的毫秒(10-3 秒)部分。
Temporal.ZonedDateTime.prototype.minute实验性-
返回一个从 0 到 59 的整数,表示此时间的分钟部分。
Temporal.ZonedDateTime.prototype.month实验性-
返回一个正整数,表示此日期在年份中基于 1 的月份索引。今年的第一个月是
1,最后一个月是monthsInYear。依赖于日历。请注意,与Date.prototype.getMonth()不同,该索引是基于 1 的。如果日历有闰月,那么具有相同monthCode的月份在不同年份可能有不同的month索引。 Temporal.ZonedDateTime.prototype.monthCode实验性-
返回一个日历特定的字符串,表示此日期的月份。依赖于日历。通常是
M加上一个两位数的月份编号。对于闰月,它是上一个月的代码后跟L。如果闰月是一年中的第一个月,代码是M00L。 Temporal.ZonedDateTime.prototype.monthsInYear实验性-
返回一个正整数,表示此日期所在年份的月份数。依赖于日历。对于 ISO 8601 日历,这总是 12,但在其他日历系统中可能会有所不同。
Temporal.ZonedDateTime.prototype.nanosecond实验性-
返回一个从 0 到 999 的整数,表示此时间的纳秒(10-9 秒)部分。
Temporal.ZonedDateTime.prototype.offset实验性-
返回一个字符串,表示用于解释内部瞬间的偏移量,格式为
±HH:mm(或±HH:mm:ss.sssssssss,并带有必要的小数秒精度)。 Temporal.ZonedDateTime.prototype.offsetNanoseconds实验性-
返回一个整数,表示用于解释内部瞬间的偏移量,以纳秒为单位(正数或负数)。
Temporal.ZonedDateTime.prototype.second实验性-
返回一个从 0 到 59 的整数,表示此时间的秒部分。
Temporal.ZonedDateTime.prototype.timeZoneId实验性-
返回一个字符串,表示用于解释内部瞬间的时区标识符。它使用构造
Temporal.ZonedDateTime对象时使用的相同字符串,可以是 IANA 时区名称或固定偏移量。 Temporal.ZonedDateTime.prototype.weekOfYear实验性-
返回一个正整数,表示此日期在
yearOfWeek中的基于 1 的周索引,如果日历没有明确定义的周系统,则返回undefined。一年的第一周是1。依赖于日历。请注意,对于 ISO 8601,一年的最初几天和最后几天可能归属于上一年的最后一周或下一年的第一周。 Temporal.ZonedDateTime.prototype.year实验性-
返回一个整数,表示此日期的年份,相对于日历特定的纪元开始年份。依赖于日历。通常,第 1 年是最新纪元的第一年或 ISO 8601 的
0001年。如果纪元在年中开始,该年在纪元开始日期前后将具有相同的值。 Temporal.ZonedDateTime.prototype.yearOfWeek实验性-
返回一个整数,表示与此日期的
weekOfYear配对的年份,如果日历没有明确定义的周系统,则返回undefined。依赖于日历。通常这是日期的年份,但对于 ISO 8601,一年的最初几天和最后几天可能归属于上一年的最后一周或下一年的第一周,导致yearOfWeek相差 1。 Temporal.ZonedDateTime.prototype[Symbol.toStringTag]-
[Symbol.toStringTag]属性的初始值是字符串"Temporal.ZonedDateTime"。此属性在Object.prototype.toString()中使用。
实例方法
Temporal.ZonedDateTime.prototype.add()实验性-
返回一个新的
Temporal.ZonedDateTime对象,表示此日期时间向前移动给定持续时间(形式可通过Temporal.Duration.from()转换)。 Temporal.ZonedDateTime.prototype.equals()实验性-
如果此日期时间与另一个日期时间(形式可通过
Temporal.ZonedDateTime.from()转换)在值上相等,则返回true,否则返回false。它们通过瞬间值、时区和日历进行比较,因此来自不同日历或时区的两个日期时间可能被Temporal.ZonedDateTime.compare()认为是相等的,但equals()不会。 Temporal.ZonedDateTime.prototype.getTimeZoneTransition()实验性-
返回一个
Temporal.ZonedDateTime对象,表示在此瞬间之后或之前的第一个时区 UTC 偏移量发生变化的瞬间,如果没有这样的转换,则返回null。这对于找出时区的偏移规则很有用,例如其夏令时模式。 Temporal.ZonedDateTime.prototype.round()实验性-
返回一个新的
Temporal.ZonedDateTime对象,表示此日期时间四舍五入到给定单位。 Temporal.ZonedDateTime.prototype.since()实验性-
返回一个新的
Temporal.Duration对象,表示从另一个日期时间(形式可通过Temporal.ZonedDateTime.from()转换)到此日期时间的持续时间。如果另一个日期时间在此日期时间之前,则持续时间为正,如果之后则为负。 Temporal.ZonedDateTime.prototype.startOfDay()实验性-
返回一个
Temporal.ZonedDateTime对象,表示此日期在时区中的第一个瞬间。它通常具有00:00:00的时间,但如果由于偏移量变化导致午夜不存在,则可能会不同,在这种情况下,将返回存在的第一个时间。 Temporal.ZonedDateTime.prototype.subtract()实验性-
返回一个新的
Temporal.ZonedDateTime对象,表示此日期时间向后移动给定持续时间(形式可通过Temporal.Duration.from()转换)。 Temporal.ZonedDateTime.prototype.toInstant()实验性-
返回一个新的
Temporal.Instant对象,表示此日期时间的瞬间。 Temporal.ZonedDateTime.prototype.toJSON()实验性-
返回一个字符串,表示此日期时间,其RFC 9557 格式与调用
toString()相同。旨在由JSON.stringify()隐式调用。 Temporal.ZonedDateTime.prototype.toLocaleString()实验性-
返回一个具有语言敏感的此日期时间表示的字符串。
Temporal.ZonedDateTime.prototype.toPlainDate()实验性-
返回一个新的
Temporal.PlainDate对象,表示此日期时间的日期部分。 Temporal.ZonedDateTime.prototype.toPlainDateTime()实验性-
返回一个新的
Temporal.PlainDateTime对象,表示此日期时间的日期和时间部分。仅移除了时区信息。 Temporal.ZonedDateTime.prototype.toPlainTime()实验性-
返回一个新的
Temporal.PlainTime对象,表示此日期时间的时间部分。 Temporal.ZonedDateTime.prototype.toString()实验性-
返回一个字符串,以 RFC 9557 格式表示此日期时间。
Temporal.ZonedDateTime.prototype.until()实验性-
返回一个新的
Temporal.Duration对象,表示从此日期时间到另一个日期时间(形式可通过Temporal.ZonedDateTime.from()转换)的持续时间。如果另一个日期时间在此日期时间之后,则持续时间为正,如果之前则为负。 Temporal.ZonedDateTime.prototype.valueOf()实验性-
抛出
TypeError,这可以防止Temporal.ZonedDateTime实例在算术或比较操作中被隐式转换为原始值。 Temporal.ZonedDateTime.prototype.with()实验性-
返回一个新的
Temporal.ZonedDateTime对象,表示此日期时间的某些字段被新值替换。 Temporal.ZonedDateTime.prototype.withCalendar()实验性-
返回一个新的
Temporal.ZonedDateTime对象,表示此日期时间在新日历系统中的解释。 Temporal.ZonedDateTime.prototype.withPlainTime()实验性-
返回一个新的
Temporal.ZonedDateTime对象,表示此日期时间的时间部分完全被新时间替换(形式可通过Temporal.PlainTime.from()转换)。 Temporal.ZonedDateTime.prototype.withTimeZone()实验性-
返回一个新的
Temporal.ZonedDateTime对象,表示与此日期时间相同的瞬间,但在新的时区中。
规范
| 规范 |
|---|
| Temporal # sec-temporal-zoneddatetime-objects |
浏览器兼容性
加载中…