第一次知道 鲜果阅读器 是在今年五月底的时候。那个时候我并不怎么在意，因为我一直是 Google Reader 的忠实用户。我一直以为鲜果是 抓虾 的 Copy 而已，并没有怎么的在意它。而近期无意间关注了下鲜果阅读器，我发现发的界面有很多的改变，功能也比刚上线的时候增强了不少。

这下有好戏看了，我要看看抓虾怎么对于这个用户群完全一样的对手了。我当初在选择在线阅读器的时候在抓虾和 Google Reader 之间犹豫不决。虽然我最后选择了当初只有英文版本的 Google Reader，但是我一直很期待 Google Reader 能像抓虾一样有一个 RSS Feed 的共享社区。

曾经有一段时间我每天上抓虾看下是否有其他「更精彩」的 Blog，然后将其拉回 Google Reader。我之所以那么「执着」的使用 Google Reader 是因为它出色的兼容性和易用性。从兼容性方面来说，Google Reader 几乎可以在任何的浏览器上使用（甚至包括了移动版本的 Opera Mini）；其次从易用性方面来说，Google Reader 几乎可以不用设置，你直接将 Rss 的链接加入 Google Reader 以后就可以了。之所以依赖 Google Reader 也部分其他的原因，就是 Firefox 能直接将 Rss 扔到 Google Reader 中。要知道，使用 Google Reader 的大部分用户同时也是 Firefox 的使用者。

说道这里似乎有点离题了，我所以看好鲜果是因为它清楚的市场定位。鲜果近期推出了「博客认领」的功能，它可以将博客和其作者对应起来。这个功能意义是非常巨大的，它摆脱了以前单一的 读者 - 读者 共享方式，使 Blog 的作者 - 读者 之间有了一个直接的交流。

鲜果的「热榜」功能则能直接的给出相应分类下订阅量最多的博客。订阅者的「羊群效应」是明显的。设想一下，刚了解怎么使用 Rss 的用户保证会满天下的寻找 Rss Feed，最终他们往往「相信」的是订阅最多的 Blog。

鲜果的「雷达」软件是在线阅读器的衍生。它可以让用户在桌面端随时知道自己的 OPML （Rss 订阅列表）更新。这是一个非常不错的功能，鲜果的确是想用户所想。

说了那么多，但是我目前还是处于观望状态。对于我「这些」原本就使用某阅读器的用户来说，适应也一种过程。Rss 阅读器本身就是一种粘性非常强的产品。

目前的鲜果已经可以用「优越」两个字来形容了，但是我个人认为还有一些细节可以考虑一下。比如用户的自身的阅读趋势。这点在 Google Reader 中本人使用的非常的频繁，因为它可以迅速知道哪些频道是许久未更新哦，哪些频道是自己最常看的。其次，将推荐或收藏（Google Reader 中称为「加注星标」和「共享」）自身生成一个 Rss Feed，这样可以被 Feedsky 等进行 Rss 合烧，让更多的读者知道我们（Blogger，内容的产生者）每天在阅读那些条目。

最后，发布一张我的 Rss 订阅比例，虽然 Google Reader 还是是以「压倒性」的优势占据了大部分的 Rss 阅读器市场。不过我有理由相信，依据目前鲜果的发展态势，完全可以有更好的作为。

由于暂时使用国外的空间，在我发布 Blog 的时候发现时间总是不对。依据我以前编写程序的经验，这是时区的问题。这个问题解决起来并不难，写下我的解决途径以便日后参考。

PHP 脚本端的市区设置可以在 php.ini 下设置 date.timezone 键的值为 'Asia/Shanghai' 即可。但是通常共享虚拟主机本身没有修改 php.ini 权限。这个时候就应该在程序公共部分加入

ini_set('date.timezone','Asia/Shanghai');

动态修改 php.ini 的设置。之后可以测试一下时间是否正确：

var_dump(date());

如果服务器的本地时间是正确的，那么一般就能解决问题了。附，PHP 5.1 以上提供了专门的函数修改对应的时区：

date_default_timezone_set('Asia/Shanghai');

建议使用此函数，因为更通用一些。对应 'Asia/Shanghai' 其他可以使用的大陆时区还有：Asia/Chongqing 、Asia/Shanghai 、Asia/Urumqi （依次为重庆，上海，乌鲁木齐）；港台地区可用：Asia/Macao、Asia/Hong_Kong、Asia/Taipei（依次为澳门，香港，台北）；还有新加坡：Asia/Singapore；其他可用的值是：Etc/GMT-8、Singapore、Hongkong、PRC；老外好像把北京漏调了。

但是，在我修改成功 PHP 端的时区以后发现日期并没有正确的记录下来。这个时候我考虑是否是数据库的问题。果不其然，因为程序插入的函数并没有调用 PHP 的时间，而是直接使用 MySQL 的 CURRECT_TIMESTAMP。这个时候就要考虑是否能修改 MySQL 方面的时区。

参考了 MySQL 的文档，发现一个可行的 SQL 语句为：

SET GLOBAL time_zone = '+8:00'; 

其中 '+8:00' 是东八区的表示方法，其他的市区依次类推。而我在数据库模型中插入改语句发现权限不够（该死的虚拟主机提供商）。接下来我调试了很多语句，比如：

DATE_ADD(UTC_TIMESTAMP(), INTERVAL 8 HOUR);

显示时区的 SQL 语句：

SHOW VARIABLES LIKE 'system_time_zone'

等等。而由于 MySQL 权限的限制并没有彻底的解决方案。我 Google 了下，发现老外这个有 一个非常好的解决方案 。但是他需要修改每条插入数据的 SQL 语句。这样的方案并不是非常的有效，一旦数据库时区改成正常，那么相应的 SQL 语句又要改回来。

而我考虑既然 PHP 端已经可以正确的解决时间的问题了。MySQL 数据库方面虽然可以使用相应的函数解决，但是如果日后迁移到别的主机环境又要改回来。而相应的字段是一个 TIMESTAMP 类型的，默认的值为 CURRECT_TIMESTAMP，当然是可以指定时间的。

那么我的做法就是让 PHP 插入当前正确的时间，这样虽然程序方面需要做相应的修改。不过日后配置修改起来只要修改一处就可以了。最后插入数据库的时间注意一下格式：

date('Y-m-d H:i:s')

这样就可以解决问题了。附，一些非常好的参考资料：

1. http://www.modwest.com/help/kb6-256.html
2. http://topic.csdn.net/t/20060503/07/4728521.html
3. http://www.phpchina.com/5173/viewspace_5132.html
4. http://www.phpx.com/pth110355.php

更新：由此 wiLdGoose 兄说他也碰到同样的问题，但是无法解决。结果经过种种的假设和判断以后，到最后发现原来是 Zend Studio 的时区配置问题（我狂汗ing）。看来除去运行环境，开发环境也是需要注意以下的。

有时候技术人员就是怕开会，毕竟有些东西我们是不关心的。但由于「种种」的原因我们不得不参加这样的会议。而在「浪费」无聊人生的同时我们伟大的技术人员就会做些「无聊的事情」，比如在会议上随手涂鸦。我 「有幸」参加了这样的会议，于是乎我就做出了些和公司「不兼容、不和×谐」的举动。

咳咳，这个是无敌猪！它身披铠甲，手持作战武器，HP 为惊人的 1e10（这辈子都不用喝红了）。但是它唯一的遗憾就是没有头发。

下面出场的是无敌猪永远的对手 -- 金刚猫。别看它弱小的身体，但是它尾巴上的蝴蝶结已经出卖了它。它那间不可摧的牙齿似乎能咬掉一切东西（沙丁鱼罐头、肉末粉丝、蟹糊酱等）。

谁说开会的时候就不能泡妞了？！下面是两只栗子的爱情故事。他们在一个阳光明媚的早晨，迎着乌鸦的叫声（淫×叫？！）。栗子哥哥终于按耐不住心中澎湃的心绪拖着一朵小花（竞猜时间：到底栗子哥哥拿的是什么花呢？猜中将本人初吻一个），向栗子妹妹表白。

上面是放大的版本，但愿栗子哥哥能成功！有关后续，Gracecode.com 会陆续报道请持续关注本 Blog！最后，在议会上涂鸦是非常不道德的行为，它破坏了公司的纪律、公司的发展以及公司对你的期望。请各位看官切勿模仿，否则被自己伟大、纯真、善良的主管看见了后果不堪设想。

附，上述涂鸦大图 打包下载 。