描述
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 |
瀏覽器相容性
載入中…