我們在用火車頭采集的時候，一般很少有人采集文檔的發(fā)布時間，基本都是采集了直接發(fā)布，所以今天我遇到一個問題，就是采集好的內(nèi)容發(fā)布到dede后，看到系統(tǒng)入庫時間為3-19，正常，但是在文章頁顯示的時間為：暫無，列表頁顯示時間為1970-01-01，確實看著很不舒服，也不知道這個會不會對程序產(chǎn)生其他影響，初步猜測是在火車頭的發(fā)布模塊出了問題。  　　還是原來的思維，能解決的話，盡量解決下，網(wǎng)上找教程。也真不太好找，找到的都是dede采集之內(nèi)的，火車頭采集雖然也是采集，但跟dede采集卻又不一樣，后來找到這樣一個，先寫在這，大家看到了一定不要嘗試，否則你會后悔的。如果你只想知道如何解決1970的問題的話，這幾段都可以略過。但希望你懂得他是如何實現(xiàn)的。  　　一、錯誤解決方案剖析  　　首先在phpMyAdmin查看dede_archives這個表的sortrank和pubdate的一個值,你的時間是1970-01-01 00:00:00他的值就是28800好像這個..你自己查看看,改現(xiàn)在現(xiàn)在的時間比如2009-08-13 00:00:00  　　的值就是1250150400  　　那么你在后臺dede_archives這個表的sortrank和pubdate 把28800替換1250150400 搞定…  　　批量替換發(fā)布時間，入庫時間，更新時間的方法。  　　首先要知道一個文章有三個時間。  　　對應的是數(shù)據(jù)庫的dede_archives表，請根據(jù)你的實際情況更換前綴。  　　這個表里有三個表示時間的字段：  　　pubdate：發(fā)布時間(前臺可更改)  　　senddate：入庫時間  　　sortrank：前臺調(diào)用最新文章。實際上是用這個時間。  　　我采集的文章不知道什么原因，入庫后都是2021年的。后面手工增加的2009年的文章。  　　在首頁等地方用pubdate排序方式都只能調(diào)出采集的2021年文章，  　　通過PHPMYADMIN查看發(fā)現(xiàn)有以上三個字段。  　　注意：里面的數(shù)值不是直觀的。  　　如不是2009-01-13 14:13:32而是1231846313  　　所以我們在批量替換的時候要這么做。  　　第一步。在后臺新增一個文章。  　　得到一個時間，比如2009-01-13 14:13:32，這可以通過管理文章那里看到。  　　第二步，后臺執(zhí)行SQL語句SELECT * FROM dede_archives order by id DESC limit 1  　　這樣你可以看到你剛才新加加的文章一所有字段值。  　　觀察以下的數(shù)據(jù)：  

pubdate：1231846313 senddate：1231846313 sortrank：1231846313

  　　其中1231846313就是時間數(shù)據(jù)了。  　　然后就是替換了。    

UPDATE dede_archives SET sortrank = 1231846313; UPDATE dede_archives SET senddate = 1231846313; UPDATE dede_archives SET pubdate = 1231846313;

　　首先，看到第一句話應該就可以pass他了，下面具體說說，他這個方法的問題在哪里(注：這種執(zhí)行sql語句，或者需要修改數(shù)據(jù)庫的一定先備份數(shù)據(jù)庫)。  　　對應的是數(shù)據(jù)庫的dede_archives表，請根據(jù)你的實際情況更換前綴。  　　這個表里有三個表示時間的字段：  　　pubdate：發(fā)布時間(前臺可更改)  　　senddate：入庫時間  　　sortrank：前臺調(diào)用最新文章。實際上是用這個時間。  　　這段說的是沒有問題的，我再詳細的說下：  　　1.pubdate：發(fā)布時間(前臺可更改)  　　在發(fā)布新文章或編輯文章時，可在高級參數(shù)里看到，可以更改。也是系統(tǒng)在內(nèi)容頁及列表頁調(diào)用的時間。當發(fā)布時間為1970時，列表頁會顯示1970-01-01，而文章頁獲取的發(fā)布時間則為“暫無”，當然這個以dede默認模板為準，如果你修改了可能會有其他結果。如：我的待審核文章審核發(fā)布時會自動更新為當前系統(tǒng)時間(如果不會設置，看Dedecms未審核文檔自動更新發(fā)布時間)  　　2.senddate：入庫時間 
  　　根據(jù)字面意思即可理解，但是所謂的入庫時間體現(xiàn)在哪里?就是dede后臺檔案列表中的“錄入時間”，理論上dede后臺無法修改，但實際也可以執(zhí)行sql語句修改，并無實際意義。如果你的文章命名規(guī)則為“{typedir}/{Y}/{M}{D}/{aid}.html”的話，也直觀的提現(xiàn)在你文章頁的url中。  　　3.sortrank：前臺調(diào)用最新文章。實際上是用這個時間。  　　這個時間我們一般看不到，但是前臺模板設置為“orderby=’public’的話，系統(tǒng)就是按照這個時間來調(diào)用的。說了一大堆只是在強調(diào)這些細節(jié)，也算是講講原理吧。  　　其次，我們應該了解，即使是火車頭采集，或者dede采集，pubdate、senddate、sortrank這三個時間也不可能完全一致，所以這里也有點問題，但是無傷大雅，最終要的在于，這個方案是修改了整個系統(tǒng)的數(shù)據(jù)庫pubdate、senddate、sortrank的三個時間段，也就是說，從你發(fā)的第一篇文章，到最后一篇，都會變成你現(xiàn)在修改的這個時間，我第一次修改之后，整站的文章都成了3月19日發(fā)布的，可以說幾乎所有的東西都亂了，這個大家應該能想明白，所以，我說備份很重要，轉載這篇文章的人，確實很害人。這種方法我覺得沒有什么可取的，完全用不上的。  　　二、正確的解決1970的方案  　　火車頭采集發(fā)布時唯一不會錯的就是系統(tǒng)錄入時間，所以，我們以這個為標準，將public及sortrank時間改為senddate(聲明下，先備份，后操作)。同時，網(wǎng)站采集比較多的考慮下，是不是有些文章的發(fā)布時間與入庫時間相差很大?如3-19采集了很多篇，發(fā)布為待審核，通過插件控制每天自動更新，4-19才更新完，如果你執(zhí)行兩條命令的話，那原來審核最晚的那些文章也會變成3-19日發(fā)布，不過你可以選擇只執(zhí)行一條命令。)  　　如果你不介意上面我說的，確實需要解決1970的問題的話，在dede后臺-系統(tǒng)-sql命令行工具，執(zhí)行以下命令：  

1 UPDATE dede_archives SET sortrank = senddate ;

  這條命令是將前臺調(diào)用時間也改成入庫時間，如果你是我上面提到的那種，就不要執(zhí)行了，至于1970還會不會有其他影響，自己斟酌  

1 UPDATE dede_archives SET pubdate = senddate ;

這條命令是將發(fā)布時間改為入庫時間，就不解釋了，上面都說了