Plone-4.3.18安装collective.datehacker用于设定Archetypes类内容的创建和修改时间，采用TZ Asia/Singapore设置解决时区问题

Plone-4.3.18 的内容有四个比较重要的日期

创建日期:'creation_date'
修改日期:'modification_date'
发布日期:'effectiveDate'
失效日期:'expirationDate'

其中发布日期和失效日期可以登录后进行修改，另两个没有提供修改功能。我的页面ZPT中列出内容时用的修改时间进行排序，出现了两个问题：一是修改或新建内容后的日期总是比实际时间晚13个小时，上午上传的就显示日期为前一天；二是如果修改了以前创建的内容，自动在排序中变为最靠前，但有时这并不是自己想要的效果。

我的页面ZPT中每个栏目只取出排序最前十几项显示，对于成百上千的内容，分类和排序意义很小，还是必须依靠搜索进行定位。所以感觉这都不是什么大问题，之前一直没有想去解决，前一段时间在网上看到了一篇文章：

http://www.315ok.org/blogfolder/658/@@base_view

设置调整内容创建、修改时间的脚本
通过ZMI将下面的python脚本文件添加到站点根：

#set creationDate and effectiveDate to a given 
datedate="-".join(traverse_subpath)
try:
    d= DateTime(date)
except:
    return "problem with subpath '%s'. usage: setdate/YYYY/MM/DD" % date
context.setModificationDate(date)
context.setCreationDate(date)
context.setEffectiveDate(date)
context.reindexObject()
return "date on '%s' successfully set to %s." % (context.title_or_id(), date)

如果是dexterity内容类型，将没用setCreationDate方法，应该直接设置creation_date属性。

看起来方法并不复杂，就起心来试着解决那两个问题，结果居然断断续续花了十几天的业余时间才解决。还是再次证明了我以前的结论“Zope/Plone中一点点小问题的解决都要大费周折”，下面将方法记录下来，怕以后又忘记了，哈哈

一、安装collective.datehacker用于设定Archetypes类内容的创建和修改时间

按315ok.org那篇博文提供的思路在ZMI中/Plone目录下新建  Script (Python)，然后登录试用，无论context.setModificationDate(‘2020-02-02‘)或context.modification_date = DateTime('2020-02-02')怎么写都不行，设定发布日期的确可以生效（但是Plone已经提供了修改界面，没意义），修改日期要么不变，要么就变为当前日期，就是不能改成设定日期，在网上搜了一堆文章，试了又试，基本上准备放弃了，还好及时搜索到了https://github.com/PloneGov-IT/collective.datehacker，文本介绍正是想要的功能，但是一看版本，2011年后就再没有更新了，再一看介绍中，居然连Plone 4.0下都没测试，WTF

TODO
====

* Register someway, somewhere, the hacking operation
* Test on Plone 4 (it must work, but is untested)

好歹作者还蛮有信心地写了句：it must work，试一试还是有必要的，我的Plone-4.3.18是用zeo模式安装的，在buildout.cfg的[buildout]、[client1]、[client2]三段中的eggs 和 zcml 序列后都加一行 collective.datehacker，停止正在运行的服务，重新buildout，完成后显示的版本是collective.datehacker = 0.1.0a0，看来pypi中的和github中的还有点儿不一样github中的是0.1.0a

启动plone，用浏览器连接出错，服务根本没起来，在buildout的世界里这太正常了，出错是常态，一次成功才是偶然。“如果一个Pythoner疯掉了，一定是被buildout给害的”，哈哈，停止正在运行的服务时发现client1和client2根本就没真正运行起来，只好用调试模式，开两个终端，

第一个：

root@mydebian204:/opt/plone/zeocluster# bin/zeoserver fg

启动正常

第二个：

root@mydebian204:/opt/plone/zeocluster# bin/client1 fg

有错误提示，没拷贝下来，大概是以下的意思

/opt/plone/buildout-cache/eggs/collective.datehacker-0.1.0a0-py2.7.egg/collective/datehacker/browser/configure.zcml中引用的Products.Archetypes.interfaces._base.IBaseObject不存在

进行修正 

将文件configure.zcml中的
Products.Archetypes.interfaces._base.IBaseObject
去掉base前的下划线，改为
Products.Archetypes.interfaces.base.IBaseObject

保存，在第二个终端再次尝试

root@mydebian204:/opt/plone/zeocluster# bin/client1 fg

人品暴发，居然没有出错，用浏览器进入也正常，说明服务启动了。用管理员权限登录，找一个 文档，在浏览器地址栏URL后加/@@hackdates，举例

原网址是一个页面
http://10.16.97.204:9080/Plone/doc_public/technotes
则直接加/@@hackdates
http://10.16.97.204:9080/Plone/doc_public/technotes/@@hackdates

原网址是一个文件
http://10.16.97.204:9080/Plone/doc_public/95.pdf/view
则只在文件后加/@@hackdates
http://10.16.97.204:9080/Plone/doc_public/95.pdf/@@hackdates

在表单中修改，保存，发现问题一解决了。当然只针对Archetypes类内容，不要指望对Dexterity类内容有效，Plone5就别想了

二、采用TZ Asia/Singapore设置解决时区问题

前文提到Plone-4.3.18修改或新建内容后的日期总是比实际时间晚13个小时，但我的debian-7.11.0-amd64的时间是对的

root@mydebian204:/opt/plone/zeocluster# date
2020年 06月 12日 星期五 23:57:30 CST

在网上搜索到了以下文章

https://stackoverflow.com/questions/14983923/plone-4-2-4-shows-incorrect-local-time-3-5-hours-ahead

说明在buildout.cfg的environment-vars环境变量中设定TZ就可以解决问题，但是Zope/Plone中问题的解决不可能这么简单，不整点儿幺蛾子出来才怪呢~！@#￥%……&*（）——+

我先在buildout.cfg的client1、client2两个段中environment-vars环境变量中设定TZ为Asia/Shanghai，运行buildout，测试时间还是不对，只是从晚13小时变为晚8小时

不必每次都buildout，太费时间，buildout只运行一次，之后可以直接改以下配置文件中TZ所在行

/opt/plone/zeocluster/parts/client1/etc/zope.conf
<environment>
    zope_i18n_compile_mo_files true
PYTHON_EGG_CACHE /opt/plone/zeocluster/var/.python-eggs
TZ Asia/Shanghai
</environment>

/opt/plone/zeocluster/parts/client2/etc/zope.conf
<environment>
    zope_i18n_compile_mo_files true
PYTHON_EGG_CACHE /opt/plone/zeocluster/var/.python-eggs
TZ Asia/Shanghai
</environment>

然后就是一通乱改，以下都试过了，就是不行

TZ CST
TZ GMT+8
TZ Asia/Hong_Kong
TZ Asia/Taipei
TZ Asia/Chongqing
TZ Asia/Shanghai

自己的强迫症得改，Asia/Shanghai还是晚了8个小时，于是我想不设在东8区，再向东试试，时差只两三个小时就无所谓了，

https://24timezones.com/time-zone/gmt+14

找到了最东面的 Pacific/Kiritimati，这样就是晚2个小时了，结果服务都没有起来，说是无效的TimeZone，我去，明明pytz是有的

root@mydebian204:/opt/plone/zeocluster# bin/zopepy

>>> import pytz
>>> pytz.all_timezones
略
>>> 'Pacific/Kiritimati' in pytz.all_timezones
True
>>> ^D
root@mydebian204:/opt/plone/zeocluster#

然后漫无目的的乱填TZ，结果试到东9区的东京 Asia/Tokyo，发现时间由设定为东8区的上海晚8小时变成了早1小时，而不是想像中的晚7小时，这就是Zope/Plone，就问你服不服，能不能理解，反正我是不能理解为什么。东京可以，那就在东8区不局限在大陆和港澳台，试了一下 Asia/Singapore 完美解决了第二个问题。就这样误打误撞地折腾出来的结果，对也不知道为什么对，错也不知道错在哪里，对Zope/Plone可以说是旧仇未雪又添新恨，哎。~！@#￥%……&*（）——+