别问，我累了。明天还在黑夜那边，还很遥远。北冰洋里的鱼，现在，不会梦见我们。
我累了，真累。我想在你的凝视中，休息片刻。
前段时间换了个手机，原来用的杂牌手写机在一次不经意的碰撞中，她的液晶屏就如同她的心一样，彻底的碎裂了。流出了黑色的液体，我猜测这大概是她的眼泪吧。
只见新人笑，不见旧人哭。为了挽回我对她犯下的错误，我决定将她的记忆导出。因为个人洁癖的使用习惯，记忆卡中并没有存放数据。通讯录也存放在了手机内存中。咨询了二十一世纪最有前途的电子商务人才 FT 之后，我认识了 PCSyncManager（点击下载，解压密码：www.xuchao.cn）。他犹如她前世的情人，凭借自己对她的了解，毫无保留的导出了手机中的数据。随后，他毫不犹豫的带着她踏上了去往天堂的航路。
嗯，神父啊，祝他们幸福和谐吧……
一直以来，公司某游戏平台使用 SQL Server 作为数据存储解决方案。为了数据的安全，每天凌晨在本机上做一次备份。但随着时间的推移，原先并没有设计到备份需求的硬件配置，尤其是外部存储这块，已经快不能满足 SQL Server 备份文件日益丰满的身姿。（这句话好像谁说过？）
为了彻底解决这个病痛，我打算为其实施远程异地备份。但查阅无数资料，均找不到较好的解决之道。大部分方案都是在备份目的地建共享目录，新增一个用户并赋权。然后在数据库端写个存储过程，添加数据库维护计划并使用这个存储过程。这样做有太多弊端：对于操作系统来说，很不安全；对于硬件架构设计来说，必须满足同一内网的条件。于是乎，放弃这样的方案。
经过几天的折腾测试，最后我采用了这样的方案。虽然比较老土，但至少 DIY 出来了，也暂时性满足了需求，缓解了阶级矛盾：
1、打开 SQL Server 企业管理器，找到数据库维护计划。
2、添加一个数据库维护计划，为其设置一个优美而和谐的名字，并选择需要操作的数据库对象。
昨晚，是一个愉快的、有意义的、充实的夜晚；昨晚，对于我的一生来说都是十分重要的一晚；昨晚，虽然是夜晚，但却是明媚、阳光的一晚。这一切，都是因为有了你，feelinglucky。
lucky 兄已在 gracecode.com 上面概述了昨夜我们之间发生的故事，这里做一个全面的流水记录。让花花草草都来羡慕我们这天上的一对、地上的一双吧。
昨晚接到一个工单，要给一个客户对帐。我和同事 Henry Xu 分别在 MySQL 和 SQL Server 做了一次查询，结果显示的时间正好相差八小时。Henry 说：“肯定是你 MySQL 的时区有问题，慢了八个小时”。我看看是啊，想起 lucky 的一篇文章，于是到 phpmyadmin 中查询：
SELECT UNIX_TIMESTAMP();
结果显示的时间戳，通过 PHP 的 date 函数转换出来，确实与那时的北京时间相差八个小时。我继续在 phpmyadmin 中查询：
SELECT NOW();
这次结果居然是正确的。暂时糊涂了，看看时间，北京时间21点多，一通电话直接找到 lucky。这里插播一则广告，本人专业出售 lucky 手机号码，有需要的 MM 请直接在下面留言，谢谢。
我们一边谈一边查资料，后来在 MySQL 手册上看到：UNIX_TIMESTAMP() 是返回世界协调时 UTC 的时间，不参照本机系统时区。网上也有一种说法：使用 UNIX_TIMESTAMP() 函数是获取不到正确的当地时间的时间戳，除非当前系统时区就在 0 时区。后来 lucky 提示使用 CURRENT_TIMESTAMP() 代替，但是由于我目前的数据库设计习惯，暂时不能接收非时间戳的值。
后面 lucky 就在说服我使用 datetime 的数据库类型。我一边写了一个小脚本：
<?php并把这个脚本放到服务器上跑了一下，结果发现两行输出居然是一样的。我纳闷，然后将脚本复制到 Zend Studio 里面，F5…… My god，原来是 Zend Studio 的问题……
$a = 0000000000; //从 phpmyadmin 中查询 SELECT UNIX_TIMESTAMP(); 后复制过来的 10 位数字
$b = time();
echo date('Y-m-d H:i:s', $a) . "<br />" . date('Y-m-d H:i:s', $b);
?>
下面复制一些与 lucky 的交流记录，谨作这一夜的纪念。
feelinglucky: http://www.modwest.com/help/kb6-256.html
feelinglucky: -_- 我搜索 “mysql 时区”竟然都是我的文章……
wiLdGoose: 是的
feelinglucky: http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html
NOW 是正确的是吧？
用 CURRENT_TIMESTAMP(), CURRENT_TIMESTAMP 看看
Synonyms for NOW()
wiLdGoose: ..........
feelinglucky: CURRENT_TIMESTAMP and CURRENT_TIMESTAMP() are synonyms for NOW().
feelinglucky: http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html#function_current-date
http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html#function_current-timestamp
wiLdGoose: 我知道的
他和 NOW() 一样的
我不要字符串的
我要整数
feelinglucky: Returns the current date and time as a value in 'YYYY-MM-DD HH:MM:SS' or YYYYMMDDHHMMSS.uuuuuu format, depending on whether the function is used in a string or numeric context. The value is expressed in the current time zone.
这个是 NOW() 的，注意最后一句
wiLdGoose: yep
NOW 是对的啊
那 UNIX_TIMESTAMP() 就乱来了?
不根据当前时区了?
feelinglucky: UTC_TIMESTAMP()(v4.1.1) Return the current UTC date and time
是 return UTC 时间
当前 UTC 时间
feelinglucky: 应该用 UNIX_TIMESTAMP
wiLdGoose: http://www.linuxrpm.com/forums/viewtopic.php?t=232
看这个
他的意思是放弃 unix_timestamp
feelinglucky: 这种说法是不对的
wiLdGoose: ?
feelinglucky: 返回 UTC 时间是有用处的，不能更改的
打个比方，两台服务器之间如果跨时区的话，时间保证会统一到 UTC 时间的
CCTV 不是经常说的嘛“格林威治时间 XXX”嫦娥一号升空
wiLdGoose: 是不是 unix_timestamp() 返回的时间和 now() 就是不一样的
先不论格式
feelinglucky: 用 CURRENT_TIMESTAMP 不行吗
wiLdGoose: 那还是一样要改代码
feelinglucky: 至少可以确定它是根据时区选项来的
wiLdGoose: 再说 CURRENT_TIMESTAMP 返回的是 datetime 格式
feelinglucky: ：（ 搞不懂为什么一定要时间戳
wiLdGoose: i like it
:D
feelinglucky: 你不会吧数据库都用时间戳设计的吧。。。
wiLdGoose: 是的
feelinglucky: 然后用 INT(10) ？
wiLdGoose: 是啊
你喜欢 datetime?
feelinglucky: 天啊
：（
wiLdGoose: 来吧 说服我
我听着
feelinglucky: 这样快不了多少的
直观方面先不说，这个都清楚
然后就是计算问题
比如获得最近一周的所有数据，你怎么办？
在一个表里面
wiLdGoose: 你是不是想说, 用 datetime 类型的数据, 可以直接用mysql的函数比较日期
feelinglucky: 或者获得星期一我要的所有打卡记录
wiLdGoose: 时间戳也有时间戳的好处嘛
datetime的话, 遇到特殊情况, 还是要 strtotime
多不完美
feelinglucky: 如果按照你的，保证会有一个 xxxx < monday and xxxx > monday 这样的 WHERE 条件
想象一下，这个不是日期的比较哦，是整形对整形的比较
wiLdGoose: 是的
feelinglucky: PHP 方面你首先要知道星期一的时间戳，然后再让数据库 WHERE 计算
wiLdGoose: 数字与数字比较, 不是比字符串与字符串比较方便么?
feelinglucky: 相比 MYSQL 一条语句就 OK，哪个完美呢
时间类型不是字符串类型 ：（
时间对于用户来看很直观，会“误认为”是字符串，但是在 mysql 内部存储还是长整型的
feelinglucky: 这个亲爱的可以 Google 一下
我以前也这样认为的，和你的做法一样，后来看了 wordpress 的数据库设计方面的一篇文章，谈到日期的数据库设计，才转变回观念来的
退一步讲，就算时间计算比整形的要低，但是毕竟用这个能方便很多
wiLdGoose: 我空了去研究一下, 先去改代码了
feelinglucky: OK，长篇大论留到 Blog 让亲爱的欣赏 ：D
wiLdGoose: 好的.
Thx.
wiLdGoose: 我晕死了
feelinglucky: ？
wiLdGoose: 我发现我用php写一个 echo time() 输出都错的
但是php配置文件已经修改的了啊.
[Date]
; Defines the default timezone used by the date functions
date.timezone = PRC
feelinglucky: ？！
ft
wiLdGoose: 我吐血了, 刚才写了一个 test.php
你看看 www.xxxx.com/test.php
feelinglucky: 对的啊
wiLdGoose: 我被忽悠了
feelinglucky: ？
wiLdGoose: 我电话你, ok?
feelinglucky: ok
关于坚持使用时间戳还是转投 datetime 的环抱，我目前还没有想好。花点时间研究一下吧。
另外有一则好消息吧，Perl 5.10.0 终于释出了。
最近公司的邮件系统出现延迟甚至丢信的情况，一直在等电信方面撤销原来的反向解析，然后到新的机房去做。暂且不谈电信这般公家单位的工作效率是如何之高、对待客户态度是如何之好，今天下午收到一封两天前注册商发来的邮件，内容如下：
关于 CN 英文域名注册及续费规则调整的通知《新》
尊敬的合作伙伴，您好：
根据 CNNIC 的最新要求，从 2007 年 12 月 20 日起，CN 英文域名的注册及续费规则进行了相应的调整，请您仔细阅读下面的调整说明：
一、注册规则的调整：
1、自 2007 年 12 月 20 日起，CN 英文域名的注册时间最长可注册 10 年；
2、新注册的 CN 英文域名退费删除期改为 4 天，即新注册 4 天内可删除退费。但 1 元特价注册的 CN 英文域名不能删除。（CN 域名 1 元将于 12 月 31 日结束）
二、续费规则的调整：
1、CN 英文域名过期后的续费时间延长至 35 天，即过期后的 35 天内，都可按正常续费价格续费；
2、为配合新规则的顺利实施，原通知中交纳 10 元/个的过期手续费暂不收取；
3、过期后 35 天后仍未续费的（即过期后的 36 天至 48 天），将进入 13 天的高价赎回期，须按 400 元/个赎回；
4、过期后 48 天仍未续费的（即高价赎回期结束后），域名将随时被删除；
5、CN 英文域名到期后，如果您未及时续费，在 WHOIS 系统中查询的到期年限将会延长一年，但这不能做为您已经续费域名的依据。实际的到期日期以您代理区的“域名管理”项目中显示的到期日期为准。
为了保证您的域名能够正常使用，请提前进行续费。
注意：通过分销平台注册的 CN 英文域名过期 35 天内可以通过分销平台进行续费，但不能做赎回的操作。赎回需要代理商与我公司联系进行手工操作。
收到这封邮件的第一反应就是马上去代理平台看哪些 CN 域名明年到期，赶紧续费。刚给一个 CN 续费后，习惯性 CNNIC 查 WHOIS，然后看到这么一则惊人的消息：
“CN域名1元体验活动”延续至2008年12月31日
为了响应广大网民日益高涨的应用热情和强烈的应用需求，进一步推动和巩固国家域名 .CN 的普及应用，促进我国互联网健康、持续发展，“CN 域名 1 元体验活动”将延续至 2008 年 12 月 31 日，即 2008 年内新注册的CN域名，仍将享受第一年 1 元注册价格。
同时，在 2007 年 3 月 7 日中午 12 点至 2007 年 12 月 31 日 24 点之间注册、注册年限为 1 年的 CN 域名，在 2008 年 1 月 1 日至 2008 年 12 月 31 日之间续第二年费用，将享受 1 元续费价格。
“CN 域名 1 元体验活动”自 2007 年 3 月 7 日开展以来，有效降低了普通网民的应用门槛，在全国范围内引起了良好的反响，CN 域名注册量已超过 840 万。
推广国家域名，降低体验门槛，惠及更多网民，是“CN 域名 1 元体验活动”自始至终的宗旨。相信随着 1 元 CN 域名体验活动的延续，国家域名普及程度将继续扩大，应用也更为深入，我国互联网应用的根基将更加牢固。
我想，乖乖，这下 .CN 真的完了……
