火车头采集发布织梦dedecms为何显示1970-01-01，如何解决？

　　后台执行SQL句子SELECT * FROM dede_archives order by id DESC limit 1

　　这样你可以看见你刚刚新加加的文章一所有数组值。

　　观察以下的数据：

　　其中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命令行工具，执行以下命令：

　　这条命令是将前台调用时间也改成入库时间，如果你是我前面提及的那个，就不要执行了，至于1970都会不会有其他影响，自己掂量

　　这条命令是将发布时间改为入库时间，就不解释了，上面都说了