整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
CSS里的text-overflow屬性能用來控制超長溢出的文字內容的顯示方式，超出的文字可以是直接截斷、用省略號表示，或用自定義的字符替代。
text-overflow的起作用環境是在一個‘block’狀態下的父元素容器里，它的inline子元素上水平方向不能換行(因為 ‘white-space: nowrap’)的情況下。要想text-overflow起作用，我們還不行能讓‘overflow’的值為visible，因為我們的目的就是不想讓超出的部分直接顯示出來。
text-overflow不僅能控制文本尾部超出部分的顯示方式，還可以控制文本開頭超出部分的顯示方式,比如：
text-overflow的幾個有效值:
clip: 超出的部分直接截斷
ellipsis: 超出的部分用省略號表示
自定義字符: 超出的部分用自定義字符表示
text-overflow用法例:
多行文本的超長截斷問題
上面介紹的text-overflow，我們只能用在單行文本的超長溢出情況，當文本換行成多行時，它就不起作用了，但實際編程中，我們經常會遇到多行文本的超長溢出控制問題。比如，空間只能顯示三行，希望在第三行結尾處超出的部分用省略號表示，怎么解決？
如果你使用的是谷歌瀏覽器，那這個問題相對容易解決，因為Webkit引擎里提供了一個控制多行文本超出溢出控制顯示CSS屬性：-webkit-line-clamp:N;
如果你需要在火狐瀏覽器上也有要求，那只能使用上面代碼里的彌補方法，就是限定限制文字父元素的高度為行高的整數倍，然后超出的部分直接截斷處理：
請點擊此處輸入圖片描述其中max-height:=line-height*行數
切版 qieban(.cn)
找到 Stack Overflow 全時最熱問題很容易，但是當前最熱問題能告訴我們現在的重要話題。在本文中，你可以了解到怎么才能得到當前最熱話題。
從下圖的交互面板中你可以得到具體問題的答案。下面，我們來看看它是怎么創建的。
交互面板的鏈接如下：https://datastudio.google.com/reporting/1UUTtohIB1fBH7e8An-6AhEn4AyU3eMjd/page/QwNg
我們可以看到：
最熱的全時 Stack Overflow 問題——九年以前創建的超過七百萬閱讀量——甚至不是一個編程問題： 我怎么才能撤銷 Git 里我最近的一次提交？
前十個最熱問題，4 個是 git 相關，3 個 JavaScript 相關，一個 Java 相關，一個 Linux 相關，一個 HTML 相關。還差什么？
前十沒有 Python 的問題。意不意外？
我們再看看最近一個季度的最熱的十個問題：
我們可以看到：
最熱的問題還是“我怎么才能撤銷 Git 里我最近的一次提交？”——最近一個季度有 40 萬個閱讀量。
編程相關的問題變了：現在 10 個問題里面有 4 個與 Python 相關。
Java 不見了——它不再出現在當前最熱的十個問題里。
觀察最熱 30 個問題的標簽的話，趨勢會更加明顯：
Java 和 SQL 已經從前 30 中掉落了。同時 Python 牢牢占據了閱讀量前 10 和前 30 的榜單之首。
你可以看到任何一個標簽的最熱問題。在查看每個標簽的最熱問題之前，你可以先猜一下 JavaScript，Python 和 go 的最熱問題是什么。
JavaScript, Python, Go: 問題各不相同
從這個面板中每個標簽的前十個問題以及它們的趨勢都一目了然。Python 開發者一直在問“用 for 來遍歷字典”，JavaScript 開發者問“我怎么才能從一個數組中移除某個元素”，Go 開發者問“字節數組轉 string 的最佳方法是什么”
人們對機器學習興趣滿滿，而 TensorFlow 是該領域最熱的項目之一。但是從最熱的問題可以看出人們還在掙扎于“用 pip 無法安裝 TensorFlow”以及他們當前的 CPU/GPU 能力問題。
TensorFlow 項目組可以用這個面板來追蹤這些問題的趨勢——比如說研究出一種傻瓜式的方法來用 pip 安裝 TensorFlow。
用這個面板你可以直接看到在任何一個季度的最熱的十個問題。比如說，我們可以來比較一下 Kotlin 在 2018 年第四季度和 2017 年第二季度的最熱十個問題：
看起來不錯：大多數 2017 年的熱門問題消失了，可以猜測，這個團隊在解決用戶遇到的常見問題方面做得很不錯。2018 年第四季度的熱門問題基本上都是新的，跟幾個月以前的完全不一樣。
以下是 Redis 的十大熱門問題：
可以看到，當前最熱門的問題是怎么在 Windows 上安裝 Redis。如果你是打算改進 Java 庫的 Redis 開發人員，這個信息對你用處不大——好在這個面板可以過濾出子標簽的信息。
我們再來看看 Redis+Java 的前十個熱門問題：
如果我們過濾 redis 和 Java，我們會看到不一樣的問題：比如說，大多數都與 Redis 和 Spring 有關。
而 Redis 和 C# 的熱門問題就大有不同了：
有意思的是，Redis+Java 的熱門問題問的是 C# 的簡要案例。也許開發者們在官方文檔中沒找到？
在這個面板上，你還可以看到每個問題有多少回答。比如說，最熱門問題“在 Rust 里如何將 String 轉換為 int”有 5 個回答。Go 語言的“把字節數組轉換為 string 的最好方法是什么”有 12 個不同的回答。
為什么在前十就停止了？你也可以接著去探索更深入的熱門前 30 問題：
你可以在 BigQuery 里面找到所有的數據。每三個月 Stack Overflow 都會公布一份他們最近的數據快照，我們可以拿來副本來做查詢。
Stack Overflow 熱門問題，當前 vs 全時
查找每個問題在某段時間內的閱讀量
首先我存下了這段時間的每個快照的副本，然后開始計算這些快照之間的閱讀量的變化。
好在查詢語句看起來很簡單：
每個標簽的熱門問題
超過一年沒有更新的當前最熱問題
英文原文：
https://towardsdatascience.com/finding-the-real-top-stack-overflow-questions-aebf35b095f1
oo long; didn't read:
1. 大多數應用中，只需要用“絕對時間 DateTime”一種技術實現即可
2. 后端應統一用 UTC 時間（包括 DB 落盤、接口定義），不應當受用戶時區或服務器時區的影響
3. 前端輸入、展示的時間，根據具體業務場景進行時區調整，以及精度調整
4. 面對不帶時間的日期，要明確區分「紀念日」與「精度不高的絕對時間」兩種用途，大部分時候你看到的日期是后者，它也應當用“確定時區的 DateTime”來實現
日期時間的處理，一直是計算機系統中看似簡單，實則經常爆雷的問題。
例如，每隔幾年，都會爆出的「千年蟲問題」的各種變種，通常因為系統在設計之初，沒有設計好日期時間的數據存儲方式，或者低估了產品設計的生命周期，導致最初選型的數據結構不夠用了。
千年蟲問題：
年紀大的程序員，都知道千年蟲問題。在 2000 年之前，很多系統用 2 位數字表示年份，這樣 99 年是它能表達的最大數值。因此 1999 年之后的一年，在這些系統中是沒有定義的，甚至可能出現多種奇怪的情況，例如“1900”、“1:00”、“19:0”（為什么？感興趣的讀者可以自己推測）。
如果說，「千年蟲」是在時間維度上缺乏前瞻性的設計導致的，那么另一種缺乏前瞻性的問題，是空間維度的，即產品全球化、跨時區帶來的問題。
全球化的產品中，如果時間的處理沒有遵循統一的標準，會讓整個系統充斥著難以理解和維護的時間轉換。各種接口的對接文檔，都不得不明確說明「這個接口的時間是什么時區的？需要如何處理？」后端服務如果需要跨國部署在多個大洲的機房時，因為服務器的時區不同，需要做大量的改造。
遺憾的是，大多情況下，產品不會一開始就有「全球化」屬性。所以在一開始，產研團隊都不會重視全球化的設計問題，很容易留下缺乏前瞻性的設計問題。
通常情況下，我們都不鼓勵「過度設計」。然而，日期時間的設計，是最不怕「過度」的。這時因為，在技術上實現一個前瞻的時間日期方案，成本并不高；但如果一開始的設計不夠，后期的升級和數據遷移工作，卻是傷筋動骨的。
在微服務之間，以及在前后端之間，建議用字符串傳遞日期時間。字符串清晰易讀，易于人工調試，帶來的開銷通常也完全可以接受。（帶大量時間數據的接口，建議考慮用 Unix Timestamp。）
如果用字符串，格式就不要自己發明了。有個非常明確的國際標準：ISO 8601（wikipedia: https://en.wikipedia.org/wiki/ISO_8601）
下面舉例是符合規范的常用格式：
注意，MySQL 中使用的字符串格式（如 2022-02-09 12:36:42）并不符合規范，不建議使用。
不同數據庫在時間日期相關對象的處理差異很大。這里單說 MySQL，因為坑不小。
MySQL 的 DateTime 數據在存儲時并不包含時區信息，因此，在讀取時也不會做任何時區的轉換。
同時，每個 MySQL 連接會話，都有「會話時區」的概念，但這個概念只影響 MySQL 的 NOW() 等有關當前時間的函數的行為，對數據中已經保存的 DateTime 沒有任何影響。
例如：
SET time_zone = '+00:00' ;
UPDATE tab SET datetime_colume = '2020-01-01 00:00:00';
SET time_zone = '+08:00' ; -- 換一個會話時區
SELECT datetime_colume FROM tab;
-- 返回值仍然是 '2020-01-01 00:00:00'，和寫入的數據一致，和會話時間無關
---------
SET time_zone = '+00:00' ;
SELECT NOW(); -- 假設返回 '2022-01-01 00:00:00'
UPDATE tab SET datetime_colume = NOW(); -- 存入的是 '2022-01-01 00:00:00'
SET time_zone = '+08:00' ; -- 換一個會話時區
SELECT NOW(); -- '2022-01-01 08:00:00' 根據時區變化了
SELECT datetime_colume FROM tab; -- '2022-01-01 00:00:00' 已經寫入的不會變各語言一般都提供了原生的 DateTime 數據類型，以表達絕對的日期時間，并且都支持上面 ISO 8601 規范的解析和格式化。
處理相對時區時，各種語言通常都是使用操作系統的時區數據庫，來轉化為絕對時區。時區數據庫需要在聯網情況下，由操作系統負責定時更新。
Unix Timestamp 在存儲、計算、傳遞環節都可以使用，可謂萬能。它唯獨不適合表達紀念日日期。
它通過一個數值表示了一個絕對時間與 Unix Epoch 時間（定義為 1970-01-01T00:00:00Z）的差值秒數。Unix Timestamp 本身已經表達了絕對時間，并不需要時區信息。
使用 Unix Timestamp 時，應特別注意選用合適的數值類型，它會影響時間表示的范圍。稍不留神，你就可能種下一個新的千年蟲。
本著不重不漏的原則，我們可以按如下表格劃分產品中的所有日期時間對象：
日期+時間 | 僅時間 | 僅日期 | |
不指明時區，無需根據用戶所在時區做轉換 | ① 表示本地的確定時間點 | ③ 表示本地重復性時間 | ⑤ 表示紀念日、節日 |
指明時區，需根據用戶所在時區做轉換 | ② 表示全球唯一確定時間點 | ④ 表示全球可理解的重復性時間 | ? 不存在的場景 |
下面逐一解釋這五種場景。
信息量包含「年月日-時分秒-時區」。這樣，就可以完全確定歷史長河中的一個無歧義的時間點。這個時間點是完全客觀的，和訪問的用戶地理位置無關，和服務器的地理位置無關，和什么都無關。
產品表現上，通常會根據查看者所在的時區來重新調整時間的顯示。
用途舉例：
包含「年月日-時分秒」，因為沒有時區信息，所以它本身并不能確定一個精確的時間點，而是只在特定的情境下才有意義。
所謂特定的情境，是因為業務場景中蘊含了時區的信息，并且是大家公認的共識。因此，本質上它仍然表示了一個絕對時間。在產品表現上，因為對時區的共識，所以不需要根據查看者的時區來調整時間的展示。
用途舉例：
和前兩類相比，去掉了「日期」這個信息，是為了描述重復性的日程。它可以是指明了時區的，也可以不指明時區，而基于人們對時區的共識去理解。
用途舉例：
日期對象幾乎只有一個有意義的用途：表示紀念日/節日。它不會包含時區信息。
認為「日期」只能用于「紀念日」，有些絕對了。但我確實查閱了很多資料，也沒有看到任何非「紀念日」用途的日期。
例如：
產品體現上，不需要根據時區調整日期的顯示。本質上，「紀念日」的邏輯，其實是人腦的不嚴謹導致的一種習慣，是不嚴謹、不客觀的習慣。不包含時區信息，就是為了滿足這種不嚴謹的習慣。
上面說過，日期對象不能包含時區。你可能會問，我需要表示“北京時間 2022 年 3 月 22 日”呢？答案是：這不是一個日期，而是一個「精度不高的絕對時間」。
很多情況下，當你想用日期時，其實很可能需要的是個「精度不高的絕對時間」。在飛書人力套件的業務中，經常會遇到這種場景。
例如，一個在美國的同學與一個在日本的同學，都在 2022 年 3 月 22 日這天從公司離職了，由同一個在北京的 HR 辦理離職事項。
可見，從我們用戶視角理解的「一個事件發生的日期」，其實是我們忽略了時間的精度。在產品全球化之前，我們通過一些默認的簡化，忽略了時間精度的問題（例如把時間都填成 00:00:00）。一旦面臨產品的全球化，就需要補齊時間、提高精度。
而補齊時間、提高精度的方式，需要根據具體的產品形態具體考慮、明確定義。
例如，在上述離職場景下，就需要按照這個公司對離職的定義來補充，可以是當地時間當天的 23:59:59，也可以是當天下班時間，如 17:00:00。
又比如，對于跨團隊的業務，例如一個同學的上級匯報線從一個美國 Leader 轉到一個日本 Leader，那么為了避免歧義，通常會約定一個確定的生效時區，如統一按照公司的總部所在地的時間來計算。
適用于上面的 ①②③④ 四種場景。
所有后端暴露的接口中的時間對象，全部以 UTC 時間表示。
同時，所有后端在存儲、計算、傳輸時間時，也統一使用 UTC 時間。由于 DB 存儲時間時，時區信息會被丟掉，因此應保證丟掉的時區，是大家明確約定清楚的無歧義的，即 UTC。這樣一來，DB 中的所有時間字段也都沒有歧義。
接口內部產生的時間，例如 CreatedAt、UpdatedAt時間，都應該轉換為 UTC 再落盤。如果直接使用了 MySQL 的NOW()函數，應確保 MySQL Session 的時區設置正確。
在前端或 BFF 負責處理用戶輸入的時間，以及展示給客戶看到的時間。包括兩個步驟：
上述兩點，是一定需要在產品設計中定義清晰的，切忌含糊不清。
不要較真兒抬杠的幾點：
由于歷史原因，DB 里已經采用北京時間保存了，那么我們可以約定+0800 時區是我們所有后端接口的時間。只要用一個確定的絕對時區，就不會有歧義，不必非要時 UTC。
也可以在后端接口的網關層處理時間轉換。不要較真那算不算 BFF，我們需要的是，時區轉換邏輯應嚴禁深入到后端的下層去。
適用于上面的 ⑤，即紀念日場景。
輸入或展示時，都不對日期做任何處理。日期對象直接保存在 DB 中。
只有真正的紀念日有必要用這種方式，應當非常謹慎。例如保存一個聯系人的生日時。
使用絕對的時差來表示時區，例如：“東 8 區”表示比世界協調時間（UTC）早 8 個小時的時區。這是個客觀的時區。
很多時候，我們關注的是一個城市或地區的時區。例如：Asia/Shanghai 表示中國時間；三字母的縮寫 EST 表示美國東部標準時間。注意，這些根據地理位置定義的時區的時差是會發生變化的，變化因素包括：可能受到當地政策的影響，或夏令時影響。
對于歷史的時間，地理時區是可以確定客觀時區的，因為沒有人會重新定義已經過去的時間。
對于未來的時間，地理時區并不能確定客觀時區。因此，如果一個未來的事件是按照非絕對時區約定的，那么它很可能變化。并且，我們的產品需要考慮到處理這種變化。
例如，中國員工發起一個“每天早 8 點”的跨國會議，那么在美國，由于夏令時的改變，冬天開會的時間和夏天是不一樣的。反之，美國員工發起的一個“每天早 8 點”的跨國會議，由于美國夏令時的變化，對中國員工的時間也是夏天和冬天不一樣的。
某些國家在夏天，會把時間調快一小時（提前一小時）。這表現為，同一個地區，在冬天和夏天用不同的絕對時區。
這樣做，是因為夏天白天很長，調整后會在白天的更早的時段上班，從而下班后有更長的天亮的時間。注意，并不是把 10 點上班調整到 9 點上班，而是全社會重新定義了 10 點提前了一小時。
一個具體的例子，在美國：
在 2021 年 3 月 14 日凌晨 1:59:59 后，下一秒就是凌晨 3:00:00。因此，美國的 2021 年 3 月 14 日凌晨 2:10:00 這個時間實際上不存在。為了兼容，根據 RFC5545，如果日程約在了這個不存在的時間，會認為是 3:10:00。
在 2021 年 11 月 7 日凌晨 1:59:59 后，下一秒是凌晨 1:00:00。因此，美國的 2021 年 11 月 7 日凌晨 1:10:00 這個時間實際上會出現兩次。為了避免歧義，根據 RFC5545，看到這個時間時，會認為是靠前的時間點。因此，除非用別國的時區來約日程，否則，美國老板是不可能約你在重疊的第二個小時內開會的。
https://en.wikipedia.org/wiki/ISO_8601
https://www.rfc-editor.org/rfc/rfc3339
https://datatracker.ietf.org/doc/html/rfc5545
https://stackoverflow.com/questions/2532729/daylight-saving-time-and-time-zone-best-practices
https://medium.com/@vivekmadurai/how-to-deal-with-date-and-time-across-time-zones-39b1bd747f35
https://medium.com/@vivekmadurai/how-to-deal-with-date-and-time-across-time-zones-39b1bd747f35
https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/customize/behavior-format-date-time-field?view=op-9-1
https://www.timeanddate.com/time/change/usa?year=2021
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
