我們在用火車頭采集的時候，一般很少有人采集文檔的發布時間，基本都是采集了直接發布，所以今天我遇到一個問題，就是采集好的內容發布到dede后，看到系統入庫時間為3-19，正常，但是在文章頁顯示的時間為：暫無，列表頁顯示時間為1970-01-01，確實看著很不舒服，也不知道這個會不會對程序產生其他影響，初步猜測是在火車頭的發布模塊出了問題。
還是原來的思維，能解決的話，盡量解決下，網上找教程。也真不太好找，找到的都是dede采集之內的，火車頭采集雖然也是采集，但跟dede采集卻又不一樣，后來找到這樣一個，先寫在這，大家看到了一定不要嘗試，否則你會后悔的。如果你只想知道如何解決1970的問題的話，這幾段都可以略過。但希望你懂得他是如何實現的。
一、錯誤解決方案剖析
首先在phpMyAdmin查看dede_archives這個表的sortrank和pubdate的一個值,你的時間是1970-01-01 00:00:00他的值就是28800好像這個..你自己查看看,改現在現在的時間比如2009-08-13 00:00:00
的值就是1250150400
那么你在后臺dede_archives這個表的sortrank和pubdate 把28800替換1250150400 搞定…
批量替換發布時間，入庫時間，更新時間的方法。
首先要知道一個文章有三個時間。
對應的是數據庫的dede_archives表，請根據你的實際情況更換前綴。
這個表里有三個表示時間的字段：
pubdate：發布時間(前臺可更改)
senddate：入庫時間
sortrank：前臺調用最新文章。實際上是用這個時間。
我采集的文章不知道什么原因，入庫后都是2021年的。后面手工增加的2009年的文章。
在首頁等地方用pubdate排序方式都只能調出采集的2021年文章，
通過PHPMYADMIN查看發現有以上三個字段。
注意：里面的數值不是直觀的。
如不是2009-01-13 14:13:32而是1231846313
所以我們在批量替換的時候要這么做。
第一步。在后臺新增一個文章。
得到一個時間，比如2009-01-13 14:13:32，這可以通過管理文章那里看到。
第二步，后臺執行SQL語句SELECT * FROM dede_archives order by id DESC limit 1
這樣你可以看到你剛才新加加的文章一所有字段值。
觀察以下的數據：
pubdate：1231846313
senddate：1231846313
sortrank：1231846313
|
其中1231846313就是時間數據了。
然后就是替換了。
UPDATE dede_archives SET sortrank = 1231846313;
UPDATE dede_archives SET senddate = 1231846313;
UPDATE dede_archives SET pubdate = 1231846313;
|
首先，看到第一句話應該就可以pass他了，下面具體說說，他這個方法的問題在哪里(注：這種執行sql語句，或者需要修改數據庫的一定先備份數據庫)。
對應的是數據庫的dede_archives表，請根據你的實際情況更換前綴。
這個表里有三個表示時間的字段：
pubdate：發布時間(前臺可更改)
senddate：入庫時間
sortrank：前臺調用最新文章。實際上是用這個時間。
這段說的是沒有問題的，我再詳細的說下：
1.pubdate：發布時間(前臺可更改)
在發布新文章或編輯文章時，可在高級參數里看到，可以更改。也是系統在內容頁及列表頁調用的時間。當發布時間為1970時，列表頁會顯示1970-01-01，而文章頁獲取的發布時間則為“暫無”，當然這個以dede默認模板為準，如果你修改了可能會有其他結果。如：我的待審核文章審核發布時會自動更新為當前系統時間(如果不會設置，看Dedecms未審核文檔自動更新發布時間)
2.senddate：入庫時間
根據字面意思即可理解，但是所謂的入庫時間體現在哪里?就是dede后臺檔案列表中的“錄入時間”，理論上dede后臺無法修改，但實際也可以執行sql語句修改，并無實際意義。如果你的文章命名規則為“{typedir}/{Y}/{M}{D}/{aid}.html”的話，也直觀的提現在你文章頁的url中。
3.sortrank：前臺調用最新文章。實際上是用這個時間。
這個時間我們一般看不到，但是前臺模板設置為“orderby=’public’的話，系統就是按照這個時間來調用的。說了一大堆只是在強調這些細節，也算是講講原理吧。
其次，我們應該了解，即使是火車頭采集，或者dede采集，pubdate、senddate、sortrank這三個時間也不可能完全一致，所以這里也有點問題，但是無傷大雅，最終要的在于，這個方案是修改了整個系統的數據庫pubdate、senddate、sortrank的三個時間段，也就是說，從你發的第一篇文章，到最后一篇，都會變成你現在修改的這個時間，我第一次修改之后，整站的文章都成了3月19日發布的，可以說幾乎所有的東西都亂了，這個大家應該能想明白，所以，我說備份很重要，轉載這篇文章的人，確實很害人。這種方法我覺得沒有什么可取的，完全用不上的。
二、正確的解決1970的方案
火車頭采集發布時唯一不會錯的就是系統錄入時間，所以，我們以這個為標準，將public及sortrank時間改為senddate(聲明下，先備份，后操作)。同時，網站采集比較多的考慮下，是不是有些文章的發布時間與入庫時間相差很大?如3-19采集了很多篇，發布為待審核，通過插件控制每天自動更新，4-19才更新完，如果你執行兩條命令的話，那原來審核最晚的那些文章也會變成3-19日發布，不過你可以選擇只執行一條命令。)
如果你不介意上面我說的，確實需要解決1970的問題的話，在dede后臺-系統-sql命令行工具，執行以下命令：
1 |
UPDATE dede_archives SET sortrank = senddate ; |
|
這條命令是將前臺調用時間也改成入庫時間，如果你是我上面提到的那種，就不要執行了，至于1970還會不會有其他影響，自己斟酌
1 |
UPDATE dede_archives SET pubdate = senddate ; |
|
這條命令是將發布時間改為入庫時間，就不解釋了，上面都說了
