初學(xué)JavaScript之?dāng)?shù)據(jù)基本類型

.數(shù)值型number

整數(shù) 10進制（默認(rèn)） 8進制（前面加0） 16進制（前面加0x）

var num10 = 23; //十進制 
var num8 = 023; //八進制 19
var num16 = 0x23; //十六進制 35
console.log("num10=", num10, "num8=", num8, 'num16=', num16);

浮點數(shù) 普通形式指數(shù)形式(科學(xué)計數(shù)法) n乘以以10（寫成e）的m次方。

var floatp = 100.123; //100.123
var floatz = 3.456e6; //3456000
console.log("floatp=", floatp, "floatz=", floatz);

2.字符串類型string

var stra = '這么大一個國家，責(zé)任非常重、工作非常艱巨。我將無我，不負人民。我愿意做到一個“無我”的狀態(tài)，為中國的發(fā)展奉獻自己。';
var strb = "2019年3月22日，意大利眾議長菲科舉行會見時的講話。";
var strc = '我將無我，不負人民。';
document.write(strc, "</br>", stra, "</br>", strb);

3.布爾值boolean，只有 ture和false

0表示false，非0表示真。

轉(zhuǎn)換成數(shù)值時：true為1，false為假。

編在這里根據(jù)知識圖譜整理了CSDN站內(nèi)的優(yōu)質(zhì)文章300篇，幫助見習(xí)工程提升技術(shù)能力、實現(xiàn)系統(tǒng)化學(xué)習(xí)！

基礎(chǔ)IT技術(shù)文章300篇大合集包含：

【信息/編碼】進制轉(zhuǎn)換25篇、數(shù)據(jù)編碼25篇；

【IP/組網(wǎng)】網(wǎng)關(guān)與網(wǎng)段25篇、IP協(xié)議26篇、主機與DNS 23篇、訪問控制37篇；

【程序邏輯】JavaScript 29篇、常用算法37篇；

【W(wǎng)eb基礎(chǔ)】HTML 31篇、CSS 32篇、DOM與BOM 23篇

在如今這個時間和知識都是碎片化的時代，C站根據(jù)C1-C4認(rèn)證的成長路徑，進行知識細化整理，形成系統(tǒng)化的知識圖譜。

歡迎關(guān)注訂閱csdn高校俱樂部，每天獲得最核心最新鮮的知識合集，助你穩(wěn)過認(rèn)證、通關(guān)大廠~

見習(xí)工程師要求具備“信息/編碼”、“IP/組網(wǎng)”、“程序邏輯”和“Web基礎(chǔ)”這四項基礎(chǔ)能力。這些基本技能都是目前一線大廠開發(fā)工作中會高頻接觸和使用的“底層邏輯”（其中程序邏輯使用 JavaScript 作為編程語言）

就軟件技術(shù)而言，熟練地進行不同進制間的計算和轉(zhuǎn)換，理解ASCII、UTF-8等字符編碼原理，掌握TCP/IP子網(wǎng)劃分、路由重組等計算機網(wǎng)絡(luò)技術(shù)，學(xué)會常用HTML標(biāo)簽、CSS樣式表和基礎(chǔ)JavaScript語法，對于后續(xù)更高級知識的學(xué)習(xí)大有裨益。

1、進制轉(zhuǎn)換文章（節(jié)選）

我們?yōu)槭裁匆獙W(xué)習(xí)進制

進制之間的轉(zhuǎn)換（二進制、八進制、十進制、十六進制）

計算機基礎(chǔ)進制轉(zhuǎn)換（二進制、八進制、十進制、十六進制）

進制轉(zhuǎn)換：二進制、八進制、十六進制、十進制之間的轉(zhuǎn)換

C語言算法之將十進制數(shù)轉(zhuǎn)換成二進制數(shù)

JAVA 進制轉(zhuǎn)換的幾個方法

C++中的各種進制轉(zhuǎn)換函數(shù)匯總

c/c++進制轉(zhuǎn)換方法匯總（含全部代碼）

2進制 , 8進制 , 10進制 , 16進制 , 介紹及相互轉(zhuǎn)換及快速轉(zhuǎn)換的方法

數(shù)據(jù)結(jié)構(gòu)練習(xí)——棧（進制轉(zhuǎn)換）

2、數(shù)據(jù)編碼（節(jié)選）

三種常用的數(shù)字?jǐn)?shù)據(jù)編碼方式

一篇文章徹底弄懂Base64編碼原理

處理分類數(shù)據(jù) 非數(shù)值型編碼

Redis數(shù)據(jù)編碼方式詳解

關(guān)于http接口開發(fā)中json格式數(shù)據(jù)編碼問題處理

關(guān)于python中pymysql數(shù)據(jù)編碼問題

[Python模塊學(xué)習(xí)]使用base64模塊進行二進制數(shù)據(jù)編碼

柵格數(shù)據(jù)的編碼方法

UTF-8與GBK互轉(zhuǎn)，為什么會亂碼？

IP/組網(wǎng)】

1、網(wǎng)關(guān)與網(wǎng)段（節(jié)選）

IP地址，子網(wǎng)掩碼、默認(rèn)網(wǎng)關(guān)，DNS服務(wù)器是什么意思?

IP地址，子網(wǎng)掩碼、默認(rèn)網(wǎng)關(guān)，DNS服務(wù)器之間的聯(lián)系與區(qū)別

VLAN基礎(chǔ)知識

網(wǎng)關(guān)和網(wǎng)段區(qū)別

VMware選擇VMnet8模式連接外網(wǎng)的方法

192.168.和10.0.開頭的IP、內(nèi)網(wǎng)IP段、IP簡介、分類——（IP觀止）

計算機網(wǎng)絡(luò): IP地址，子網(wǎng)掩碼，網(wǎng)段表示法，默認(rèn)網(wǎng)關(guān)，DNS服務(wù)器詳解

指定網(wǎng)段走指定網(wǎng)卡網(wǎng)關(guān)方法

Vmware設(shè)置靜態(tài)ip連網(wǎng) （使用自定義Vmnet8 net ）

計算機網(wǎng)絡(luò)——不同網(wǎng)段下的主機通信

2、IP協(xié)議（節(jié)選）

太厲害了，終于有人能把TCP/IP 協(xié)議講的明明白白了

實現(xiàn)基于 TCP/IP 協(xié)議簡單的客戶端、服務(wù)器通信程序?qū)嵗?/p>

網(wǎng)絡(luò)協(xié)議、socket、webSocket

Windows 無法自動將 IP 協(xié)議堆棧綁定到網(wǎng)絡(luò)適配器

面試時，你被問到過 TCP/IP 協(xié)議嗎?

TCP/IP協(xié)議組——完整工作過程分析

《TCP/IP詳解卷1:協(xié)議》PDF分享

TCP/IP協(xié)議簡述+常見面試題

wireshark抓包分析——TCP/IP協(xié)議

TCP/IP協(xié)議四層模型

以下是300篇文章的全部目錄哦

CSDN軟件工程師能力認(rèn)證（以下簡稱C系列認(rèn)證）是由中國軟件開發(fā)者網(wǎng)CSDN制定并推出的一個能力認(rèn)證標(biāo)準(zhǔn)。C系列認(rèn)證歷經(jīng)近一年的實際線下調(diào)研、考察、迭代、測試，并梳理出軟件工程師開發(fā)過程中所需的各項技術(shù)技能，結(jié)合企業(yè)招聘需求和人才應(yīng)聘痛點，基于公開、透明、公正的原則，甑別人才時確保真實業(yè)務(wù)場景、全部上機實操、所有過程留痕、存檔不可篡改。

熱點文章：

最受歡迎主流Java框架文章50篇：spring mvc、Hibernate、structs

普通本科生怎么進大廠？大廠招聘JD詳解
CSDN高校俱樂部名師百校行——河北站

版權(quán)聲明：本文為CSDN「高校俱樂部」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。

oo long; didn't read:
1. 大多數(shù)應(yīng)用中，只需要用“絕對時間 DateTime”一種技術(shù)實現(xiàn)即可
2. 后端應(yīng)統(tǒng)一用 UTC 時間（包括 DB 落盤、接口定義），不應(yīng)當(dāng)受用戶時區(qū)或服務(wù)器時區(qū)的影響
3. 前端輸入、展示的時間，根據(jù)具體業(yè)務(wù)場景進行時區(qū)調(diào)整，以及精度調(diào)整
4. 面對不帶時間的日期，要明確區(qū)分「紀(jì)念日」與「精度不高的絕對時間」兩種用途，大部分時候你看到的日期是后者，它也應(yīng)當(dāng)用“確定時區(qū)的 DateTime”來實現(xiàn)

1. 重要性

日期時間的處理，一直是計算機系統(tǒng)中看似簡單，實則經(jīng)常爆雷的問題。

例如，每隔幾年，都會爆出的「千年蟲問題」的各種變種，通常因為系統(tǒng)在設(shè)計之初，沒有設(shè)計好日期時間的數(shù)據(jù)存儲方式，或者低估了產(chǎn)品設(shè)計的生命周期，導(dǎo)致最初選型的數(shù)據(jù)結(jié)構(gòu)不夠用了。

千年蟲問題：
年紀(jì)大的程序員，都知道千年蟲問題。在 2000 年之前，很多系統(tǒng)用 2 位數(shù)字表示年份，這樣 99 年是它能表達的最大數(shù)值。因此 1999 年之后的一年，在這些系統(tǒng)中是沒有定義的，甚至可能出現(xiàn)多種奇怪的情況，例如“1900”、“1:00”、“19:0”（為什么？感興趣的讀者可以自己推測）。

如果說，「千年蟲」是在時間維度上缺乏前瞻性的設(shè)計導(dǎo)致的，那么另一種缺乏前瞻性的問題，是空間維度的，即產(chǎn)品全球化、跨時區(qū)帶來的問題。

全球化的產(chǎn)品中，如果時間的處理沒有遵循統(tǒng)一的標(biāo)準(zhǔn)，會讓整個系統(tǒng)充斥著難以理解和維護的時間轉(zhuǎn)換。各種接口的對接文檔，都不得不明確說明「這個接口的時間是什么時區(qū)的？需要如何處理？」后端服務(wù)如果需要跨國部署在多個大洲的機房時，因為服務(wù)器的時區(qū)不同，需要做大量的改造。

遺憾的是，大多情況下，產(chǎn)品不會一開始就有「全球化」屬性。所以在一開始，產(chǎn)研團隊都不會重視全球化的設(shè)計問題，很容易留下缺乏前瞻性的設(shè)計問題。

通常情況下，我們都不鼓勵「過度設(shè)計」。然而，日期時間的設(shè)計，是最不怕「過度」的。這時因為，在技術(shù)上實現(xiàn)一個前瞻的時間日期方案，成本并不高；但如果一開始的設(shè)計不夠，后期的升級和數(shù)據(jù)遷移工作，卻是傷筋動骨的。

2. 如何表達時間和日期？

2.1 時間日期的傳遞：用字符串

在微服務(wù)之間，以及在前后端之間，建議用字符串傳遞日期時間。字符串清晰易讀，易于人工調(diào)試，帶來的開銷通常也完全可以接受。（帶大量時間數(shù)據(jù)的接口，建議考慮用 Unix Timestamp。）

如果用字符串，格式就不要自己發(fā)明了。有個非常明確的國際標(biāo)準(zhǔn)：ISO 8601（wikipedia: https://en.wikipedia.org/wiki/ISO_8601）

下面舉例是符合規(guī)范的常用格式：

僅日期：2022-02-09
UTC 日期時間：2022-02-09T12:36:42Z
特定時區(qū)的日期時間：2022-02-09T20:36:42+08:00
精度更高的時間：2022-02-09T12:36:42.123456789Z

注意，MySQL 中使用的字符串格式（如 2022-02-09 12:36:42）并不符合規(guī)范，不建議使用。

2.2 時間日期的存儲：關(guān)注 MySQL 中的 DateTime

不同數(shù)據(jù)庫在時間日期相關(guān)對象的處理差異很大。這里單說 MySQL，因為坑不小。

MySQL 的 DateTime 數(shù)據(jù)在存儲時并不包含時區(qū)信息，因此，在讀取時也不會做任何時區(qū)的轉(zhuǎn)換。

同時，每個 MySQL 連接會話，都有「會話時區(qū)」的概念，但這個概念只影響 MySQL 的 NOW() 等有關(guān)當(dāng)前時間的函數(shù)的行為，對數(shù)據(jù)中已經(jīng)保存的 DateTime 沒有任何影響。

例如：

SET time_zone =  '+00:00' ;
UPDATE tab SET datetime_colume = '2020-01-01 00:00:00';
SET time_zone =  '+08:00' ;  -- 換一個會話時區(qū)
SELECT datetime_colume FROM tab;
-- 返回值仍然是 '2020-01-01 00:00:00'，和寫入的數(shù)據(jù)一致，和會話時間無關(guān)

---------
SET time_zone =  '+00:00' ;
SELECT NOW();   -- 假設(shè)返回 '2022-01-01 00:00:00'
UPDATE tab SET datetime_colume = NOW();   -- 存入的是 '2022-01-01 00:00:00'
SET time_zone =  '+08:00' ;  -- 換一個會話時區(qū)
SELECT NOW();   -- '2022-01-01 08:00:00' 根據(jù)時區(qū)變化了
SELECT datetime_colume FROM tab;   -- '2022-01-01 00:00:00' 已經(jīng)寫入的不會變

2.3 時間日期的計算：語言原生的 DateTime 類型

各語言一般都提供了原生的 DateTime 數(shù)據(jù)類型，以表達絕對的日期時間，并且都支持上面 ISO 8601 規(guī)范的解析和格式化。

處理相對時區(qū)時，各種語言通常都是使用操作系統(tǒng)的時區(qū)數(shù)據(jù)庫，來轉(zhuǎn)化為絕對時區(qū)。時區(qū)數(shù)據(jù)庫需要在聯(lián)網(wǎng)情況下，由操作系統(tǒng)負責(zé)定時更新。

2.4 萬能的 Unix Timestamp

Unix Timestamp 在存儲、計算、傳遞環(huán)節(jié)都可以使用，可謂萬能。它唯獨不適合表達紀(jì)念日日期。

它通過一個數(shù)值表示了一個絕對時間與 Unix Epoch 時間（定義為 1970-01-01T00:00:00Z）的差值秒數(shù)。Unix Timestamp 本身已經(jīng)表達了絕對時間，并不需要時區(qū)信息。

使用 Unix Timestamp 時，應(yīng)特別注意選用合適的數(shù)值類型，它會影響時間表示的范圍。稍不留神，你就可能種下一個新的千年蟲。

用有符號int32，最多表示到 2038 年。MySQL 的 TIMESTAMP 類型也是它，一個千年蟲變種
用有符號int64，并使用 9 位 10 進制定點小數(shù)位時，就是 Golang 的UnixNano()，可以表示 1678 年至 2262 年
一般不會用浮點數(shù)表示，因為浮點數(shù)的精度不固定

3. 產(chǎn)品視角的日期時間設(shè)計

本著不重不漏的原則，我們可以按如下表格劃分產(chǎn)品中的所有日期時間對象：

	日期+時間	僅時間	僅日期
不指明時區(qū)，無需根據(jù)用戶所在時區(qū)做轉(zhuǎn)換	① 表示本地的確定時間點	③ 表示本地重復(fù)性時間	⑤ 表示紀(jì)念日、節(jié)日
指明時區(qū)，需根據(jù)用戶所在時區(qū)做轉(zhuǎn)換	② 表示全球唯一確定時間點	④ 表示全球可理解的重復(fù)性時間	? 不存在的場景

下面逐一解釋這五種場景。

3.1 表示全球唯一確定時間點（表中的 ②）

信息量包含「年月日-時分秒-時區(qū)」。這樣，就可以完全確定歷史長河中的一個無歧義的時間點。這個時間點是完全客觀的，和訪問的用戶地理位置無關(guān)，和服務(wù)器的地理位置無關(guān)，和什么都無關(guān)。

產(chǎn)品表現(xiàn)上，通常會根據(jù)查看者所在的時區(qū)來重新調(diào)整時間的顯示。

用途舉例：

單個事件發(fā)生的時間。如 2022 年冬奧會開幕式的時間：2022 年 2 月 4 日，20 點整，+0800 時區(qū)。一個英國人看電視轉(zhuǎn)播預(yù)告時，會看到開幕式的轉(zhuǎn)播時間是：2022 年 2 月 4 日中午 12 點整。這體現(xiàn)了根據(jù)查看者做時間的轉(zhuǎn)換。

3.2 表示本地的確定時間點（表中的 ①）

包含「年月日-時分秒」，因為沒有時區(qū)信息，所以它本身并不能確定一個精確的時間點，而是只在特定的情境下才有意義。

所謂特定的情境，是因為業(yè)務(wù)場景中蘊含了時區(qū)的信息，并且是大家公認(rèn)的共識。因此，本質(zhì)上它仍然表示了一個絕對時間。在產(chǎn)品表現(xiàn)上，因為對時區(qū)的共識，所以不需要根據(jù)查看者的時區(qū)來調(diào)整時間的展示。

用途舉例：

在非國際化的產(chǎn)品中，明確知道用戶所在的時區(qū)，那么去掉時區(qū)是最簡單的處理方式，可以省去很多麻煩。
對于時區(qū)有其他約定俗成的理解。例如：飛機的起飛降落時間，酒店的入住離店時間，一定是按照飛機起落地、酒店坐落地當(dāng)?shù)貢r區(qū)來表達的。在所有訂票網(wǎng)站上，都會按照這個規(guī)則顯示時間，不論訪問的用戶身處哪個時區(qū)。

3.3 表示重復(fù)性時間（表中的 ③ 和 ④）

和前兩類相比，去掉了「日期」這個信息，是為了描述重復(fù)性的日程。它可以是指明了時區(qū)的，也可以不指明時區(qū)，而基于人們對時區(qū)的共識去理解。

用途舉例：

每周三 8:00+0800 開會，如果這可以是個跨國的會議，大家都能理解正確的時間。這時，產(chǎn)品表現(xiàn)上應(yīng)該注意根據(jù)查看者來調(diào)整顯示。
每周三 8:00 起飛的航班，航班起飛地的時區(qū)是蘊含的共識。產(chǎn)品表現(xiàn)中不必根據(jù)查看者的時區(qū)調(diào)整顯示。

3.4 紀(jì)念日日期（表中的 ⑤）

日期對象幾乎只有一個有意義的用途：表示紀(jì)念日/節(jié)日。它不會包含時區(qū)信息。

認(rèn)為「日期」只能用于「紀(jì)念日」，有些絕對了。但我確實查閱了很多資料，也沒有看到任何非「紀(jì)念日」用途的日期。

例如：

小吳的生日是 3 月 11 日，那么不管他在中國還是美國，都會在 3 月 11 日這一天過生日。
每年 12 月 25 日是西方的圣誕節(jié)，各個國家都在 12 月 25 日這一天慶祝，雖然它們并不在同一個時區(qū)。

產(chǎn)品體現(xiàn)上，不需要根據(jù)時區(qū)調(diào)整日期的顯示。本質(zhì)上，「紀(jì)念日」的邏輯，其實是人腦的不嚴(yán)謹(jǐn)導(dǎo)致的一種習(xí)慣，是不嚴(yán)謹(jǐn)、不客觀的習(xí)慣。不包含時區(qū)信息，就是為了滿足這種不嚴(yán)謹(jǐn)?shù)牧?xí)慣。

3.5 區(qū)分「紀(jì)念日日期」與「精度不高的絕對時間」

上面說過，日期對象不能包含時區(qū)。你可能會問，我需要表示“北京時間 2022 年 3 月 22 日”呢？答案是：這不是一個日期，而是一個「精度不高的絕對時間」。

很多情況下，當(dāng)你想用日期時，其實很可能需要的是個「精度不高的絕對時間」。在飛書人力套件的業(yè)務(wù)中，經(jīng)常會遇到這種場景。

例如，一個在美國的同學(xué)與一個在日本的同學(xué)，都在 2022 年 3 月 22 日這天從公司離職了，由同一個在北京的 HR 辦理離職事項。

可見，從我們用戶視角理解的「一個事件發(fā)生的日期」，其實是我們忽略了時間的精度。在產(chǎn)品全球化之前，我們通過一些默認(rèn)的簡化，忽略了時間精度的問題（例如把時間都填成 00:00:00）。一旦面臨產(chǎn)品的全球化，就需要補齊時間、提高精度。

而補齊時間、提高精度的方式，需要根據(jù)具體的產(chǎn)品形態(tài)具體考慮、明確定義。

例如，在上述離職場景下，就需要按照這個公司對離職的定義來補充，可以是當(dāng)?shù)貢r間當(dāng)天的 23:59:59，也可以是當(dāng)天下班時間，如 17:00:00。

又比如，對于跨團隊的業(yè)務(wù)，例如一個同學(xué)的上級匯報線從一個美國 Leader 轉(zhuǎn)到一個日本 Leader，那么為了避免歧義，通常會約定一個確定的生效時區(qū)，如統(tǒng)一按照公司的總部所在地的時間來計算。

4. 日期時間的技術(shù)實現(xiàn)

4.1 確定時區(qū)的 DateTime

適用于上面的 ①②③④ 四種場景。

所有后端暴露的接口中的時間對象，全部以 UTC 時間表示。

同時，所有后端在存儲、計算、傳輸時間時，也統(tǒng)一使用 UTC 時間。由于 DB 存儲時間時，時區(qū)信息會被丟掉，因此應(yīng)保證丟掉的時區(qū)，是大家明確約定清楚的無歧義的，即 UTC。這樣一來，DB 中的所有時間字段也都沒有歧義。

接口內(nèi)部產(chǎn)生的時間，例如 CreatedAt、UpdatedAt時間，都應(yīng)該轉(zhuǎn)換為 UTC 再落盤。如果直接使用了 MySQL 的NOW()函數(shù)，應(yīng)確保 MySQL Session 的時區(qū)設(shè)置正確。

在前端或 BFF 負責(zé)處理用戶輸入的時間，以及展示給客戶看到的時間。包括兩個步驟：

處理“精度不高的時間”問題。 比如：員工異動的生效時間，用戶只設(shè)置到“天”的精度。那么如果不跨國，可以補全用戶會話時區(qū)的 00:00:00 為精確生效時間；如果跨國，那就看客戶如何定義，以及產(chǎn)品給客戶怎樣的靈活性：例如，可以以客戶公司總部所在地的時區(qū)的 00:00:00 為精確生效的時間。
時區(qū)轉(zhuǎn)換。 注意，這里不一定是使用用戶的會話時區(qū)來轉(zhuǎn)換。如前面介紹的飛機火車賓館的預(yù)定時間，就要以預(yù)定當(dāng)?shù)氐臅r區(qū)來轉(zhuǎn)換。

上述兩點，是一定需要在產(chǎn)品設(shè)計中定義清晰的，切忌含糊不清。

不要較真兒抬杠的幾點：
由于歷史原因，DB 里已經(jīng)采用北京時間保存了，那么我們可以約定+0800 時區(qū)是我們所有后端接口的時間。只要用一個確定的絕對時區(qū)，就不會有歧義，不必非要時 UTC。
也可以在后端接口的網(wǎng)關(guān)層處理時間轉(zhuǎn)換。不要較真那算不算 BFF，我們需要的是，時區(qū)轉(zhuǎn)換邏輯應(yīng)嚴(yán)禁深入到后端的下層去。

4.2 不帶時區(qū)的 Date

適用于上面的 ⑤，即紀(jì)念日場景。

輸入或展示時，都不對日期做任何處理。日期對象直接保存在 DB 中。

只有真正的紀(jì)念日有必要用這種方式，應(yīng)當(dāng)非常謹(jǐn)慎。例如保存一個聯(lián)系人的生日時。

5. 關(guān)于時區(qū)的特殊處理

5.1 時區(qū)的不確定性

使用絕對的時差來表示時區(qū)，例如：“東 8 區(qū)”表示比世界協(xié)調(diào)時間（UTC）早 8 個小時的時區(qū)。這是個客觀的時區(qū)。

很多時候，我們關(guān)注的是一個城市或地區(qū)的時區(qū)。例如：Asia/Shanghai 表示中國時間；三字母的縮寫 EST 表示美國東部標(biāo)準(zhǔn)時間。注意，這些根據(jù)地理位置定義的時區(qū)的時差是會發(fā)生變化的，變化因素包括：可能受到當(dāng)?shù)卣叩挠绊懀蛳牧顣r影響。

對于歷史的時間，地理時區(qū)是可以確定客觀時區(qū)的，因為沒有人會重新定義已經(jīng)過去的時間。

對于未來的時間，地理時區(qū)并不能確定客觀時區(qū)。因此，如果一個未來的事件是按照非絕對時區(qū)約定的，那么它很可能變化。并且，我們的產(chǎn)品需要考慮到處理這種變化。

例如，中國員工發(fā)起一個“每天早 8 點”的跨國會議，那么在美國，由于夏令時的改變，冬天開會的時間和夏天是不一樣的。反之，美國員工發(fā)起的一個“每天早 8 點”的跨國會議，由于美國夏令時的變化，對中國員工的時間也是夏天和冬天不一樣的。

5.2 夏令時

某些國家在夏天，會把時間調(diào)快一小時（提前一小時）。這表現(xiàn)為，同一個地區(qū)，在冬天和夏天用不同的絕對時區(qū)。

這樣做，是因為夏天白天很長，調(diào)整后會在白天的更早的時段上班，從而下班后有更長的天亮的時間。注意，并不是把 10 點上班調(diào)整到 9 點上班，而是全社會重新定義了 10 點提前了一小時。

一個具體的例子，在美國：

在 2021 年 3 月 14 日凌晨 1:59:59 后，下一秒就是凌晨 3:00:00。因此，美國的 2021 年 3 月 14 日凌晨 2:10:00 這個時間實際上不存在。為了兼容，根據(jù) RFC5545，如果日程約在了這個不存在的時間，會認(rèn)為是 3:10:00。

在 2021 年 11 月 7 日凌晨 1:59:59 后，下一秒是凌晨 1:00:00。因此，美國的 2021 年 11 月 7 日凌晨 1:10:00 這個時間實際上會出現(xiàn)兩次。為了避免歧義，根據(jù) RFC5545，看到這個時間時，會認(rèn)為是靠前的時間點。因此，除非用別國的時區(qū)來約日程，否則，美國老板是不可能約你在重疊的第二個小時內(nèi)開會的。

閱讀更多及參考文獻

Wikipedia: ISO8601 - 用字符串表達各種時間對象的標(biāo)準(zhǔn)

https://en.wikipedia.org/wiki/ISO_8601

RFC3339 - 互聯(lián)網(wǎng)上關(guān)于時間和日期實現(xiàn)的通用建議

https://www.rfc-editor.org/rfc/rfc3339

RFC5545 - iCalendar 互聯(lián)網(wǎng)日歷應(yīng)用的規(guī)范

https://datatracker.ietf.org/doc/html/rfc5545

Stackoverflow: Daylight saving time and time zone best practices [closed] - 技術(shù)實現(xiàn)建議

https://stackoverflow.com/questions/2532729/daylight-saving-time-and-time-zone-best-practices

Stackoverflow: How to store repeating dates keeping in mind daylight saving time - 技術(shù)實現(xiàn)建議

https://medium.com/@vivekmadurai/how-to-deal-with-date-and-time-across-time-zones-39b1bd747f35

Medium: How to Deal with Date and Time across Time Zones - 技術(shù)實現(xiàn)建議

https://medium.com/@vivekmadurai/how-to-deal-with-date-and-time-across-time-zones-39b1bd747f35

Microsoft365: Behavior and format options of the Date and Time field - 微軟的時間和日期字段的文檔

https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/customize/behavior-format-date-time-field?view=op-9-1

Time Change 2021 in the United States - 美國 2021 年夏令時的調(diào)整方式

https://www.timeanddate.com/time/change/usa?year=2021

在線咨詢

上一篇：HTML5常用標(biāo)簽大全
下一篇：用CSS實現(xiàn)居中的七種方法

您的項目需求

*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。

整合營銷服務(wù)商

初學(xué)JavaScript之?dāng)?shù)據(jù)基本類型

1. 重要性

2. 如何表達時間和日期？

2.1 時間日期的傳遞：用字符串

2.2 時間日期的存儲：關(guān)注 MySQL 中的 DateTime

2.3 時間日期的計算：語言原生的 DateTime 類型

2.4 萬能的 Unix Timestamp

3. 產(chǎn)品視角的日期時間設(shè)計

3.1 表示全球唯一確定時間點（表中的 ②）

3.2 表示本地的確定時間點（表中的 ①）

3.3 表示重復(fù)性時間（表中的 ③ 和 ④）

3.4 紀(jì)念日日期（表中的 ⑤）

3.5 區(qū)分「紀(jì)念日日期」與「精度不高的絕對時間」

4. 日期時間的技術(shù)實現(xiàn)

4.1 確定時區(qū)的 DateTime

4.2 不帶時區(qū)的 Date

5. 關(guān)于時區(qū)的特殊處理

5.1 時區(qū)的不確定性

5.2 夏令時

閱讀更多及參考文獻

您的項目需求

2. 如何表達時間和日期？