【校正回歸】的內容，在資料處理的領域常常見到，中文我們更常稱為「數據回補」、「資料回溯」等等，確實不會講【回歸】，因為第一時間，容易誤會成統計學的「回歸分析(Regression)」。
英文在國外慣用字應是backlog，但在小馬經驗中，早期曾經提過幾次，發現當下幾乎沒有人能理解(包括工程師)……甚至會雞同鴨講以為我在講log或歷史資料。
於是放棄，後續我都直接以中文說明，並直接舉例。
在系統上，通常會以Create Date與System Date做記錄，可以這樣理解：
Create Date：輸入(key in)進系統裡的日期
System Date：此筆資料按定義上應認列的日期
例如某個銷售員在5/22 (Create Date) 進系統，輸入自己在5/20 (System Date) 的業績是74萬。就像是在5/22，CDC公布了在5/20有74人是校正回歸，道理是一模一樣的。
且各家ERP使用Create Date為輸入日的狀況還蠻一致的，所以後端工程師，一講Create Date大致都能秒懂意思，比backlog效果還好。
使用上差異在於，如果是以Create Date為公布數據的使用日期，則數據會每天固定，5/22當天就會是721人，而沒有什麼【校正回歸】(如圖一)；如果是以System Date為公布日期，則往後的每個日期都可能會【校正回歸】前面的日期，換言之前面日期的數據將無法固定。兩種日期各有利弊，訴求不同的人會想看不同的使用日期。
小馬我自己是覺得，
大家都大人了，有什麼好做選擇的呢？
全都要不行嗎？(無誤)
想看固定數據就用Create Date (輸入系統日, 個案研判日)；
想看回補數據就用System Date (檢測日, 認列日)。
兩種使用日期的數據都公布嘛！豈不皆大歡喜？
如圖實際案例，即是當初user要求「出過的數字不能變動」，結果PM沒意識到，讓工程師以習慣的System Date去做，驗收時被user發現怎麼前面的數據每天都在浮動，於是小馬只好救火將其改為Create Date去做……(5/6那篇就是在講這事)……所以這事蠻常見就是了。
=====A FEW MONENTS LEATER=====
今天中午CDC公布了：採檢日(左上)、發病日(右上)、研判日(左下)、校正後(右下)。其中研判日即是CreateDate，每日數據可固定不浮動。
此舉給予正面肯定，可說是從善如流，各種日期全部公布，就不會再有各種紛擾。(還好這篇文發得比記者會早，免了馬後炮的疑慮。)