時(shí)間戳這個(gè)東西看起來(lái)是“取個(gè)時(shí)間嘛”的小事但毫秒級(jí)的互轉(zhuǎn)一旦做錯(cuò)排查起來(lái)比內(nèi)存泄漏還讓人頭疼。我最近整理一套上報(bào)系統(tǒng)的日志字段時(shí)看到老代碼里還散落著time(NULL)取秒、再自己湊毫秒的寫(xiě)法心里特別沒(méi)底。C11 的chrono其實(shí)早已把取毫秒這件事封裝得很順手關(guān)鍵是你得知道用哪個(gè)時(shí)鐘、怎么解析字符串、時(shí)區(qū)語(yǔ)義怎么定。這篇就把我沉淀下來(lái)的方案完整寫(xiě)出來(lái)從獲取當(dāng)前毫秒時(shí)間戳到日期字符串和毫秒時(shí)間戳互轉(zhuǎn)最后給一個(gè)能直接放進(jìn)工程的工具類。寫(xiě) C 的朋友也別急著走里面的坑和思路是通用的代碼只是 C11 的殼。1. 為什么是毫秒而不是秒日志和監(jiān)控讓秒級(jí)時(shí)間戳現(xiàn)了原形1.1 秒的粒度在日志和監(jiān)控里真的不夠用單看“日期時(shí)間格式帶不帶毫秒”好像只是多三個(gè)數(shù)字的區(qū)別但真實(shí)業(yè)務(wù)里差距非常大。我遇到過(guò)最典型的場(chǎng)景是耗時(shí)抖動(dòng)排查。服務(wù)接口平均 200ms某次流量高峰后出現(xiàn)一批 3500ms 的超時(shí)請(qǐng)求。如果日志時(shí)間戳只精確到秒輸出大概是這樣子的2024-01-15 14:30:25 INFO request finished, cost: 3560ms時(shí)間戳停留在14:30:25完全看不清這次超時(shí)是從哪一秒開(kāi)始、和哪一次流量波峰重疊。如果日志里帶著.123、.900這樣的毫秒精度按時(shí)間排序后就能準(zhǔn)確還原出“上游在某毫秒內(nèi)突然打進(jìn)來(lái)一批請(qǐng)求”“數(shù)據(jù)庫(kù)連接池在那幾毫秒里卡住”這樣的因果鏈路。另一個(gè)常見(jiàn)需求是任務(wù)跨天、跨分鐘歸屬。比如某個(gè)定時(shí)任務(wù)在23:59:59.800開(kāi)始處理到第二天00:00:00.250結(jié)束。如果只按秒級(jí)時(shí)間戳統(tǒng)計(jì)這條任務(wù)可能會(huì)被歸到 23 號(hào)而不是 24 號(hào)如果協(xié)議里的結(jié)算、對(duì)賬、積分流水也依賴這個(gè)時(shí)間差一天可是大事故。毫秒時(shí)間戳雖然不能根治業(yè)務(wù)邏輯問(wèn)題但至少能把順序關(guān)系看清楚誰(shuí)先到、誰(shuí)后到、誰(shuí)在哪個(gè)窗口里過(guò)期。對(duì)后臺(tái)服務(wù)、日志系統(tǒng)、監(jiān)控上報(bào)、設(shè)備通信協(xié)議來(lái)說(shuō)毫秒精度早已是標(biāo)配不是可選項(xiàng)。1.2 老代碼里的 time(NULL) 和 gettimeofday 為什么別扭翻老 C/C 項(xiàng)目最常看到的是這幾類做法time(NULL)拿到秒級(jí)time_t然后手動(dòng)* 1000湊毫秒。結(jié)果就是根本拿不到真毫秒只能硬編。用gettimeofday()拿timeval這是 POSIX 接口Windows 下沒(méi)有等價(jià)物為了跨平臺(tái)得額外包一層#ifdef。在 Windows 下改用GetSystemTimeAsFileTime()但這函數(shù)給的單位是 100 納秒還得換算直接勸退不少人。更野一點(diǎn)的做法是二次封裝一堆_ftime64、localtime_s不同編譯器參數(shù)順序還不一樣代碼里全是宏。這些方案不是不能用問(wèn)題是每個(gè)平臺(tái)一套語(yǔ)義不統(tǒng)一而且很容易在“秒轉(zhuǎn)毫秒”“毫秒取秒”的過(guò)程中把溢出和時(shí)間溢出搞錯(cuò)。C11 標(biāo)準(zhǔn)庫(kù)的chrono把時(shí)鐘、時(shí)間點(diǎn)、時(shí)長(zhǎng)統(tǒng)一抽象出來(lái)目的就是讓我們少寫(xiě)這些平臺(tái)適配。它不是性能最好的方案但它是跨平臺(tái)語(yǔ)義最清晰、最不容易寫(xiě)錯(cuò)的方案。后面所有代碼我都默認(rèn)目標(biāo)環(huán)境支持 C11。2. 從 system_clock 里安全取出毫秒別再碰 high_resolution_clock2.1 為什么不能隨便選 high_resolution_clock很多初學(xué)者看完網(wǎng)上的例子習(xí)慣寫(xiě)出這樣一行auto now std::chrono::high_resolution_clock::now();這行代碼看起來(lái)通用實(shí)際上隱藏著一個(gè)大坑high_resolution_clock不保證基于 Unix epoch也不保證能換算成日期。它在不少實(shí)現(xiàn)里只是steady_clock的別名計(jì)時(shí)起點(diǎn)可能是系統(tǒng)啟動(dòng)時(shí)間甚至可能是某個(gè)隨機(jī)時(shí)刻。你拿去測(cè)代碼耗時(shí)沒(méi)問(wèn)題但拿它當(dāng)“當(dāng)前時(shí)間的毫秒時(shí)間戳”去和日歷日期互轉(zhuǎn)結(jié)果完全不可控。正確的選擇只有一個(gè)std::chrono::system_clock。這個(gè)名字里的“system”指的就是系統(tǒng)的墻上時(shí)鐘它在 C11 標(biāo)準(zhǔn)里被定義為能表示系統(tǒng)范圍的實(shí)時(shí)時(shí)鐘時(shí)間點(diǎn)可以和time_t互通多數(shù)實(shí)現(xiàn)直接基于 Unix epoch。我們要做“毫秒時(shí)間戳和日期互轉(zhuǎn)”必須用它。2.2 從 time_point 到 int64_t核心代碼其實(shí)就幾行獲取當(dāng)前毫秒時(shí)間戳的完整寫(xiě)法如下#include chrono #include cstdint int64_t now_utc_ms() { auto now std::chrono::system_clock::now(); return std::chrono::duration_caststd::chrono::milliseconds( now.time_since_epoch()) .count(); }拆開(kāi)看三步system_clock::now()返回一個(gè)time_point它代表“當(dāng)前這個(gè)時(shí)刻”在某個(gè)時(shí)鐘坐標(biāo)系里的位置。.time_since_epoch()把這個(gè)時(shí)間點(diǎn)轉(zhuǎn)換成自 epoch 以來(lái)的時(shí)長(zhǎng)。對(duì)system_clock來(lái)說(shuō)epoch 一般就是1970-01-01 00:00:00 UTC。duration_castmilliseconds把時(shí)長(zhǎng)強(qiáng)制切到毫秒精度.count()取出對(duì)應(yīng)的整數(shù)毫秒數(shù)。這里的關(guān)鍵是你必須理解time_point和duration的分工前者是“墻上的一點(diǎn)”后者是“一段時(shí)間”。很多人被chrono的模板類型繞暈其實(shí)只要記住這個(gè)分工后面所有轉(zhuǎn)換都順了。2.3 有時(shí)要拆出“秒 毫秒余數(shù)”兩種寫(xiě)法看著辦有些場(chǎng)景不只要總毫秒數(shù)還希望拿到“整秒部分”和“毫秒余數(shù)”。這時(shí)候不要用兩次system_clock::now()那在兩次調(diào)用之間系統(tǒng)時(shí)間可能已經(jīng)前進(jìn)了幾微秒造成秒和毫秒對(duì)不齊。正確做法是只取一次時(shí)間點(diǎn)再分別切auto now std::chrono::system_clock::now(); int64_t total_ms std::chrono::duration_caststd::chrono::milliseconds(now.time_since_epoch()).count(); int64_t sec_part total_ms / 1000; int32_t ms_part total_ms % 1000;因?yàn)閠otal_ms本身就是 epoch 以來(lái)的總毫秒數(shù)除以 1000 的商就是整秒余數(shù)就是毫秒。這里要提醒一句上面的除法和取模對(duì)total_ms 0的場(chǎng)景不成立因?yàn)?C11 的整數(shù)除法是向零截?cái)嗟?。比?1 / 1000在數(shù)學(xué)上是-0.001向零截?cái)嗪蟮玫?余數(shù)是-1。如果你要支持 1970 年以前的時(shí)間戳這里必須特殊處理我后面在格式化章節(jié)會(huì)專門(mén)說(shuō)。平臺(tái)精度其實(shí)不必?fù)?dān)心Windows 上system_clock::now()底層通常是GetSystemTimeAsFileTime()提供的精度是 100 納秒Linux 上一般基于clock_gettime(CLOCK_REALTIME)能到納秒。取毫秒完全是降維使用。3. 日期字符串轉(zhuǎn)毫秒時(shí)間戳解析、轉(zhuǎn)換與“UTC還是本地時(shí)間”的抉擇3.1 先看看 std::get_time 方案能寫(xiě)但坑不少很多人第一反應(yīng)是用std::get_time解析日期字符串#include iomanip #include sstream std::tm tm{}; std::istringstream ss(2024-01-15 14:30:25); ss std::get_time(tm, %Y-%m-%d %H:%M:%S);這段代碼在多數(shù)編譯器上能跑但有幾個(gè)長(zhǎng)期被低估的問(wèn)題get_time不會(huì)幫你解析毫秒字段。字符串里帶.123就得先切掉或者再單獨(dú)讀一次。如果輸入是 ISO 8601 風(fēng)格2024-01-15T14:30:25.123Z格式串還要改成%Y-%m-%dT%H:%M:%S而且 Windows 標(biāo)準(zhǔn)庫(kù)的get_time實(shí)現(xiàn)和 Linux 上的行為存在微妙差異對(duì)輸入流里空白的處理方式可能不同。解析之后多余字符不一定被自動(dòng)檢查。字符串尾部多了一個(gè)空格或亂字符你很難立刻發(fā)現(xiàn)。默認(rèn)情況下std::istringstream會(huì)跳過(guò)輸入開(kāi)頭的空白但日期字符串內(nèi)部的空格需要格式串精確匹配某些舊編譯器的get_time實(shí)現(xiàn)在這里翻過(guò)車。所以我的建議是項(xiàng)目里的緊湊代碼不要用它做“日期字符串轉(zhuǎn)時(shí)間戳”的主邏輯get_time更適合交互式配置解析這種寬松場(chǎng)景。生產(chǎn)環(huán)境互轉(zhuǎn)往下看。3.2 用 sscanf %n 做嚴(yán)格解析可讀性和正確性都能保住我實(shí)際用的解析函數(shù)長(zhǎng)這樣#include cstdio #include cstring #include string bool parse_ms(const std::string text, int64_t out_ms, bool utc true) { std::string t text; // 兼容 ISO 8601: 2024-01-15T14:30:25.123Z if (t.size() 10 t[10] T) { t[10] ; } if (!t.empty() t.back() Z) { t.pop_back(); } int y 0, mo 0, d 0, h 0, mi 0, s 0, ms 0; int consumed 0; int n sscanf(t.c_str(), %4d-%2d-%2d %2d:%2d:%2d.%3d%n, y, mo, d, h, mi, s, ms, consumed); if (n 7 || consumed 0) { return false; } // 嚴(yán)格檢查字符串必須被完全消費(fèi)允許尾部空白 while (consumed static_castint(t.size()) (t[consumed] || t[consumed] \t || t[consumed] \r || t[consumed] \n)) { consumed; } if (consumed ! static_castint(t.size())) { return false; } std::tm tmv{}; tmv.tm_year y - 1900; tmv.tm_mon mo - 1; tmv.tm_mday d; tmv.tm_hour h; tmv.tm_min mi; tmv.tm_sec s; tmv.tm_isdst 0; time_t secs 0; if (utc) { #ifdef _WIN32 secs _mkgmtime(tmv); #else secs timegm(tmv); #endif } else { tmv.tm_isdst -1; secs mktime(tmv); } out_ms static_castint64_t(secs) * 1000 ms; return true; }幾個(gè)設(shè)計(jì)點(diǎn)我展開(kāi)說(shuō)一下。第一用%4d而不是%d能限制年份最多讀 4 位避免20240115 143025這種粘連字符串被錯(cuò)誤拆開(kāi)。雖然正常日志不會(huì)這么寫(xiě)但解析函數(shù)面對(duì)不可信數(shù)據(jù)時(shí)嚴(yán)格是好事。第二%n是 sscanf 的“當(dāng)前已消費(fèi)字符數(shù)”輸出它不參與返回值計(jì)數(shù)。所以判斷順序是先看n 7有 7 個(gè)有效字段再看consumed是否把整個(gè)字符串吃干凈。尾部允許少量空白但不允許出現(xiàn)2024-01-15 14:30:25.123abc這種內(nèi)容。第三utc參數(shù)決定了字符串的語(yǔ)義。utc true表示輸入的日期時(shí)間就是 UTC 時(shí)刻utc false表示這是本地時(shí)間。這是最容易埋雷的地方下一節(jié)細(xì)說(shuō)。第四毫秒字段%3d最多讀 3 位。如果字符串是2024-01-15 14:30:25.1會(huì)被解析成 1 毫秒如果是2024-01-15 14:30:25.100就是 100 毫秒。為了避免歧義業(yè)務(wù)日志最好強(qiáng)制寫(xiě)滿 3 位。3.3 本地時(shí)間還是 UTCmktime 與 timegm 的差異必須說(shuō)透這是日期字符串轉(zhuǎn)時(shí)間戳里最重要的語(yǔ)義問(wèn)題。同樣的字符串2024-01-15 14:30:25在 UTC8 時(shí)區(qū)如果按本地時(shí)間理解對(duì)應(yīng) epoch 毫秒數(shù)會(huì)比按 UTC 理解少 8 小時(shí)整整 28800000 毫秒。我見(jiàn)過(guò)的很多事故都是把“日志里打印出來(lái)的人類可讀時(shí)間”當(dāng)成了絕對(duì)時(shí)間然后直接用它去做時(shí)間計(jì)算。實(shí)際上日志打印的字符串是什么時(shí)區(qū)取決于格式化時(shí)用了localtime還是gmtime解析時(shí)也必須保持一致。mktime(tm)把tm當(dāng)成系統(tǒng)當(dāng)前時(shí)區(qū)的本地時(shí)間換算成 epoch 秒。它自己會(huì)處理時(shí)區(qū)偏移也會(huì)修改tm的tm_wday、tm_yday字段。對(duì)帶夏令時(shí)的地區(qū)還依賴tm_isdst標(biāo)志。timegm(tm)把tm當(dāng)成 UTC 時(shí)間直接換算成 epoch 秒。它是 GNU 擴(kuò)展Windows 上沒(méi)有Windows 對(duì)應(yīng)的是_mkgmtime(tm)。_mkgmtime(tm)MSVC 提供的 UTC 版本和timegm行為一致。所以代碼里用了條件編譯#ifdef _WIN32 secs _mkgmtime(tmv); #else secs timegm(tmv); #endif如果不需要支持 1970 年前的場(chǎng)景在使用_mkgmtime/timegm之前把tmv.tm_isdst設(shè)置成0就夠了它能避免一部分未初始化內(nèi)存導(dǎo)致的隨機(jī)結(jié)果。補(bǔ)一個(gè)常見(jiàn)誤區(qū)有人為了省事先timegm把 UTC 轉(zhuǎn)成 epoch再調(diào)localtime展示完全沒(méi)問(wèn)題但要小心解析方向和展示方向必須配對(duì)。解析時(shí)按本地時(shí)間展示時(shí)卻用 UTC最后存庫(kù)的時(shí)間戳?xí)詣?dòng)偏移幾個(gè)小時(shí)而且這類問(wèn)題特別難發(fā)現(xiàn)因?yàn)樗辉诳鐣r(shí)區(qū)的服務(wù)器上看得出異常。3.4 不想依賴系統(tǒng)時(shí)區(qū)函數(shù)手寫(xiě)日期算法更可控如果寫(xiě)的是嵌入式、核心路由或?qū)蓽y(cè)試性要求很高的代碼可能連timegm都不想讓它們依賴系統(tǒng) TZ 環(huán)境。這時(shí)可以直接用日期算法把“年月日時(shí)分秒毫秒”算成 epoch 毫秒完全按 UTC 或固定偏移解釋。這是我在項(xiàng)目中用的一個(gè)純函數(shù)版本避免平臺(tái)差異int64_t days_from_civil(int y, int m, int d) { y - m 2; const int era (y 0 ? y : y - 399) / 400; const unsigned yoe static_castunsigned(y - era * 400); const unsigned doy (153 * (m (m 2 ? -3 : 9)) 2) / 5 d - 1; const unsigned doe yoe * 365 yoe / 4 - yoe / 100 doy; return era * 146097 static_castint64_t(doe) - 719468; }配合關(guān)系式int64_t seconds days_from_civil(y, mo, d) * 86400 h * 3600 mi * 60 s; out_ms seconds * 1000 ms;這套算法來(lái)自現(xiàn)代 C20chrono日期底層實(shí)現(xiàn)的公開(kāi)推算邏輯我自己在項(xiàng)目里驗(yàn)證過(guò)多年跨度包括閏年邊界。優(yōu)點(diǎn)是不依賴平臺(tái)宏、不依賴 TZ、純輸入輸出非常適合單元測(cè)試。代價(jià)是沒(méi)有本地時(shí)間語(yǔ)義。如果你真的需要“把本地時(shí)間字符串轉(zhuǎn)成 epoch 毫秒”那就躲不開(kāi)mktime它內(nèi)部要查系統(tǒng)時(shí)區(qū)規(guī)則。所以我的最終建議是業(yè)務(wù)內(nèi)部統(tǒng)一用 UTC 字符串解析時(shí)也走utc true只有面向用戶展示時(shí)才轉(zhuǎn)成本地時(shí)間。4. 毫秒時(shí)間戳轉(zhuǎn)回日期字符串格式化、補(bǔ)零和線程安全4.1 先拆秒和毫秒負(fù)數(shù)時(shí)間戳要單獨(dú)處理從int64_t total_ms轉(zhuǎn)成日期字符串第一步永遠(yuǎn)是拆整數(shù)int64_t sec_part total_ms / 1000; int32_t ms_part static_castint32_t(total_ms % 1000);如前面提到的負(fù)數(shù)時(shí) C 整數(shù)除法向零取整total_ms -1會(huì)得到sec_part 0, ms_part -1。直接拿去格式化秒和毫秒拼出來(lái)就是畸形的1970-01-01 00:00:00.-1。所以正式格式化前要做一個(gè)逆標(biāo)準(zhǔn)化if (ms_part 0) { sec_part - 1; ms_part 1000; }這個(gè)是毫秒時(shí)間戳互轉(zhuǎn)里最常見(jiàn)也最少有人寫(xiě)的細(xì)節(jié)。別覺(jué)得 1970 年之前不重要設(shè)備上報(bào)、歷史回放、跨時(shí)區(qū)結(jié)算都可能遇到負(fù)時(shí)間戳而且萬(wàn)一某個(gè)中間件傳了一個(gè)壞值你至少不會(huì)打印出完全沒(méi)法解析的字符串。4.2 localtime 與 gmtime 的線程安全版本跨平臺(tái)宏就兩行拿到sec_part之后需要把它拆成年月日時(shí)分秒。絕不建議直接用localtime或gmtime這兩個(gè)函數(shù)在傳統(tǒng)實(shí)現(xiàn)里返回的是靜態(tài)緩沖區(qū)指針多線程下數(shù)據(jù)會(huì)被互相覆蓋。正確做法是用帶_r或_s后綴的線程安全版本。我一般封裝成這樣#include ctime #include cstdint inline void safe_break_time(int64_t sec, bool utc, std::tm out) { time_t raw static_casttime_t(sec); #ifdef _WIN32 if (utc) { gmtime_s(out, raw); } else { localtime_s(out, raw); } #else if (utc) { gmtime_r(raw, out); } else { localtime_r(raw, out); } #endif }這里最大的坑是參數(shù)順序。Windows 的gmtime_s/localtime_s第一個(gè)參數(shù)是輸出tm*第二個(gè)是輸入const time_t*Linux 的gmtime_r/localtime_r第一個(gè)參數(shù)是輸入const time_t*第二個(gè)才是輸出tm*。順序?qū)懛床粫?huì)編譯報(bào)錯(cuò)但運(yùn)行結(jié)果完全亂掉。cast成time_t也要注意。如果你在 32 位系統(tǒng)上用了老的 32 位time_tsec_part超過(guò) 2038 年就會(huì)溢出表現(xiàn)是日期“回到”1901 年?，F(xiàn)代 64 位系統(tǒng)基本沒(méi)有這個(gè)問(wèn)題但寫(xiě)跨平臺(tái)庫(kù)時(shí)最好自己確認(rèn)下time_t的寬度。4.3 用 snprintf 補(bǔ)零格式化輸出串一眼就能對(duì)齊拆完tm和毫秒余數(shù)格式化就簡(jiǎn)單了。我推薦直接用snprintf不繞彎子#include cstdio std::string format_ms(int64_t total_ms, bool utc true) { int64_t sec_part total_ms / 1000; int32_t ms_part static_castint32_t(total_ms % 1000); if (ms_part 0) { sec_part - 1; ms_part 1000; } std::tm tmv{}; safe_break_time(sec_part, utc, tmv); char buf[40]; snprintf(buf, sizeof(buf), %04d-%02d-%02d %02d:%02d:%02d.%03d, tmv.tm_year 1900, tmv.tm_mon 1, tmv.tm_mday, tmv.tm_hour, tmv.tm_min, tmv.tm_sec, ms_part); return std::string(buf); }幾個(gè)格式位%04d保證年份四位%02d保證月、日、時(shí)、分、秒兩位%03d保證毫秒三位。輸出風(fēng)格是2024-01-15 14:30:25.123。如果要存日志文件或上報(bào)協(xié)議我建議統(tǒng)一成這個(gè)格式因?yàn)槿祟惪勺x、機(jī)器也能用同一套parse_ms原樣解析回去。如果想輸出 ISO 8601 UTC 字符串把格式改成%04d-%02d-%02dT%02d:%02d:%02d.%03dZ并且在調(diào)用safe_break_time時(shí)傳入utc true這樣日志里能明確看到Z后綴跨系統(tǒng)追溯時(shí)不會(huì)誤判時(shí)區(qū)。5. 一個(gè)可以直接帶走的跨平臺(tái)工具類完整代碼與性能實(shí)測(cè)心得5.1 完整頭文件拷貝進(jìn)項(xiàng)目就能用前面幾段把原理拆開(kāi)了這里我把它們整合成一個(gè)不依賴第三方庫(kù)的頭文件。假設(shè)你的項(xiàng)目就是 C11文件名我一般叫MillisClock.h。#pragma once #include chrono #include cstdint #include cstdio #include ctime #include string namespace millisclock { inline int64_t now_ms() { auto now std::chrono::system_clock::now(); return std::chrono::duration_caststd::chrono::milliseconds( now.time_since_epoch()) .count(); } inline void safe_break_time(int64_t sec, bool utc, std::tm out) { time_t raw static_casttime_t(sec); #ifdef _WIN32 if (utc) { gmtime_s(out, raw); } else { localtime_s(out, raw); } #else if (utc) { gmtime_r(raw, out); } else { localtime_r(raw, out); } #endif } inline bool parse_ms(const std::string text, int64_t out_ms, bool utc true) { std::string t text; if (t.size() 10 t[10] T) { t[10] ; } if (!t.empty() t.back() Z) { t.pop_back(); } int y 0, mo 0, d 0, h 0, mi 0, s 0, ms 0; int consumed 0; int n sscanf(t.c_str(), %4d-%2d-%2d %2d:%2d:%2d.%3d%n, y, mo, d, h, mi, s, ms, consumed); if (n 7 || consumed 0) { return false; } while (consumed static_castint(t.size()) (t[consumed] || t[consumed] \t || t[consumed] \r || t[consumed] \n)) { consumed; } if (consumed ! static_castint(t.size())) { return false; } std::tm tmv{}; tmv.tm_year y - 1900; tmv.tm_mon mo - 1; tmv.tm_mday d; tmv.tm_hour h; tmv.tm_min mi; tmv.tm_sec s; tmv.tm_isdst 0; time_t secs 0; if (utc) { #ifdef _WIN32 secs _mkgmtime(tmv); #else secs timegm(tmv); #endif } else { tmv.tm_isdst -1; secs mktime(tmv); } out_ms static_castint64_t(secs) * 1000 ms; return true; } inline std::string format_ms(int64_t total_ms, bool utc true) { int64_t sec_part total_ms / 1000; int32_t ms_part static_castint32_t(total_ms % 1000); if (ms_part 0) { sec_part - 1; ms_part 1000; } std::tm tmv{}; safe_break_time(sec_part, utc, tmv); char buf[40]; snprintf(buf, sizeof(buf), %04d-%02d-%02d %02d:%02d:%02d.%03d, tmv.tm_year 1900, tmv.tm_mon 1, tmv.tm_mday, tmv.tm_hour, tmv.tm_min, tmv.tm_sec, ms_part); return std::string(buf); } } // namespace millisclockLinux 上如果編譯器沒(méi)開(kāi) GNU 擴(kuò)展timegm會(huì)編譯失敗。兩個(gè)解決辦法一是編譯時(shí)加-D_GNU_SOURCE二是干脆在文件頂部加#if !defined(_WIN32) #define _GNU_SOURCE 1 #endif必須放在所有系統(tǒng)頭文件之前。如果你不想碰宏把utc true的解析換成第 3 章的days_from_civil純算法也能完全擺脫timegm。5.2 性能實(shí)測(cè)心得別在熱路徑上反復(fù)調(diào) mktime有人會(huì)擔(dān)心這些轉(zhuǎn)換函數(shù)的開(kāi)銷尤其是日志系統(tǒng)每秒輸出幾十萬(wàn)行時(shí)。我實(shí)測(cè)下來(lái)的感受是format_ms的主要成本在localtime_r/gmtime_r它內(nèi)部每次都要查時(shí)區(qū)規(guī)則、校正夏時(shí)令狀態(tài)。而parse_ms的主要成本在mktime/timegm特別是本地時(shí)間模式下mktime會(huì)做一次完整的日歷歸一化。在我手頭一臺(tái)普通服務(wù)上純循環(huán)調(diào)用format_ms100 萬(wàn)次大概能感覺(jué)到明顯的耗時(shí)但通常只有幾百毫秒級(jí)別如果一次服務(wù)啟動(dòng)要格式化幾億條日志那就不能在一個(gè)轉(zhuǎn)換上斤斤計(jì)較而是要考慮用第 3.4 節(jié)的days_from_civil算法替換gmtime_r純整數(shù)運(yùn)算會(huì)快很多。對(duì)固定時(shí)區(qū)做緩存。例如你的服務(wù)只在 UTC8 運(yùn)行可以把時(shí)區(qū)偏移緩存成一個(gè)常量避免每次調(diào)用都走 TZ 環(huán)境變量。日志模塊批量刷盤(pán)時(shí)一次格式化一批再統(tǒng)一寫(xiě)減少上下文切換和鎖競(jìng)爭(zhēng)。順便說(shuō)一句日志里面如果既要人類可讀字符串又要 epoch 毫秒最好兩個(gè)都打印出來(lái)。比如int64_t t millisclock::now_ms(); LOG_INFO(time_ms%lld time_str%s, t, millisclock::format_ms(t).c_str());這樣排查問(wèn)題時(shí)用字符串肉眼定位用time_ms做跨進(jìn)程排序兩邊互相印證。5.3 業(yè)務(wù)約定統(tǒng)一存儲(chǔ)為 UTC 毫秒展示時(shí)再轉(zhuǎn)本地工具類只是“術(shù)”真正讓團(tuán)隊(duì)少踩坑的其實(shí)是“約定”。我現(xiàn)在的項(xiàng)目里定下三條鐵律存儲(chǔ)、傳輸、計(jì)算的內(nèi)部時(shí)間一律用int64_tUTC 毫秒任何數(shù)據(jù)庫(kù)表、協(xié)議字段、日志字段都這么定義。只有日志展示、用戶界面輸出才允許出現(xiàn)本地時(shí)間字符串而且必須帶時(shí)區(qū)或調(diào)用明確的format_ms(...)函數(shù)。所有外部輸入的日期字符串入口處統(tǒng)一用parse_ms解析一次轉(zhuǎn)成 UTC 毫秒后內(nèi)部流轉(zhuǎn)不要再保留字符串格式到處傳。這樣做的好處是數(shù)據(jù)在系統(tǒng)內(nèi)部永遠(yuǎn)是同一種語(yǔ)義不會(huì)因?yàn)槟撑_(tái)服務(wù)器TZ沒(méi)配置、某臺(tái)機(jī)器被設(shè)置成不同時(shí)區(qū)導(dǎo)致毫秒值錯(cuò)位。以前我見(jiàn)過(guò)最頭疼的問(wèn)題就是同一份日志一臺(tái)機(jī)器打印出來(lái)是14:30另一臺(tái)是22:30兩邊還在對(duì)著一個(gè)時(shí)間戳吵架。6. 我在實(shí)際項(xiàng)目里踩過(guò)的坑和最后幾條建議6.1 夏令時(shí)會(huì)讓“本地時(shí)間解析”徹底變得不可預(yù)測(cè)mktime配合tm_isdst -1看起來(lái)能自動(dòng)判斷夏令時(shí)但真實(shí)情況是一旦系統(tǒng)時(shí)區(qū)跨過(guò)春季夏令時(shí)切換日某段本地時(shí)間根本不存在秋季切換時(shí)某段本地時(shí)間又會(huì)重復(fù)出現(xiàn)。解析2024-03-10 02:30:00這類時(shí)間結(jié)果可能比你預(yù)期多一小時(shí)也可能少一小時(shí)。如果業(yè)務(wù)涉及跨境、跨季節(jié)調(diào)度我強(qiáng)烈建議不要用“本地時(shí)間字符串 絕對(duì)時(shí)間”這種模型。要么所有字符串本身就是 UTC要么解析時(shí)固定按一個(gè)業(yè)務(wù)區(qū)偏移解釋。用utc true永遠(yuǎn)比依賴mktime判斷夏令時(shí)更可控。6.2 system_clock 會(huì)隨系統(tǒng)時(shí)間跳變計(jì)時(shí)別拿它做system_clock是墻上時(shí)鐘NTP 同步、管理員手動(dòng)改時(shí)間都會(huì)讓它瞬間跳變。如果拿它去計(jì)算定時(shí)任務(wù)的剩余毫秒數(shù)或者拿兩次now_ms()的差值當(dāng)耗時(shí)系統(tǒng)時(shí)間一旦回?fù)芫蜁?huì)出現(xiàn)負(fù)值調(diào)度邏輯可能直接亂掉。正確分工是記錄事件發(fā)生的時(shí)間戳用system_clock測(cè)量一段代碼的執(zhí)行耗時(shí)用steady_clock。steady_clock是單調(diào)時(shí)鐘不受系統(tǒng)時(shí)間調(diào)整影響。兩條線不要混著用否則線上會(huì)冒出很多“不可能”的負(fù)耗時(shí)。6.3 最后幾條實(shí)在建議解析函數(shù)返回bool而不是默默返回0是我改代碼時(shí)最堅(jiān)持的一點(diǎn)。一個(gè)非法日期字符串如果被解析成“1970 年 1 月 1 日”后續(xù)排查成本遠(yuǎn)高于讓調(diào)用方立刻感知失敗。單元測(cè)試?yán)镒钪档眉拥挠美褪峭禂嘌詉nt64_t t 1705307425123; std::string s millisclock::format_ms(t, true); int64_t back 0; assert(millisclock::parse_ms(s, back, true)); assert(back t);這個(gè)用例能同時(shí)覆蓋格式化、解析、補(bǔ)零邏輯還可以順手測(cè)一下負(fù)數(shù)、跨年、閏年邊界。工具類在系統(tǒng)里跑久了真正出問(wèn)題的往往不是普通日期而是這些邊界值。我還喜歡在日志輸出的最前面統(tǒng)一帶上毫秒時(shí)間戳整數(shù)比如[1705307425123]這樣即使后續(xù)格式調(diào)整了外部工具也能根據(jù)整數(shù)字段精確排序。別小看這些細(xì)節(jié)線上事故排查的時(shí)候多一個(gè)可復(fù)現(xiàn)的毫秒錨點(diǎn)往往比多查兩小時(shí)日志有價(jià)值得多。