JCLI诞生记（一）

前阵子AliyunCLI开源，同时转变为社区维护软件，这让我第一次有了自己做一个CLI的想法，同时想改进一下CLI的内部实现方法：AliyunCLI为了判断产品的endpoint和Action名字，需要依赖对应产品的SDK，在日常的工单处理中，用户在安装SDK时出现的问题比较多，且由于对代码和SDK不甚了解，排查起来有些困难，所以就想做一个纯粹的CLI，他只负责两件事情：一是签名的计算；二是将参数拼接成URL，显示出来或者直接提交。
由于该工具使用Java编写，暂定名为JCLI。

公共参数Timestamp

这里的时间，并不是通常指的那个流逝的“时间”，而是人们定义的“时间”规则，如UTC、GMT等等国际上标准的时间表示和记录方法。阿里云API中，绝大部分产品都有“公共参数”这么一说，而其中也都有Timestamp这个参数，除了标识请求的时间以外，还有一个原因是为了防止中间人攻击，提高签名被猜出的难度。

根据阿里云的官方定义，这个值是请求时的UTC时间，日期格式按照ISO8601标准表示，当时搜了一下网上获取UTC时间的方法，发现五花八门，同时反编译了阿里云官方SDK，发现其中使用了以下的代码来获取UTC时间：

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'");
sdf.setTimeZone(new SimpleTimeZone(0, "GMT"));
return sdf.format(new Date());

时区ID

其中setTimeZone这个方法，还需要传入SimpleTimeZone这个对象，研究了一下发现使用TimeZone这个类的getTimeZone(String ID)也可以实现类似的方法，省去了一些开销，决定使用TimeZone。于是乎，需要先了解TimeZone工厂方法：TimeZone.getTimeZone。研究之后发现其中传入的getTimeZone这个方法的ID这个参数，查阅了JDK API，发现这个参数竟然可以传三种类型的参数：常规的地区/城市的格式（如America/Los_Angeles）、字母的时区简写（如CTS）和标准化的时间计算方法的名称（如GMT），可以传三种格式的时区字符串呀，很黄很暴力。由于对后两者传入方式不熟悉，打算使用完整的城市名称。联想到UTC时间，就是英国伦敦当地时间嘛，然后就去翻java的ZoneInfo文件，想找一下java关于地区/城市名字的定义，然后就在openjdk的文件夹（jdkmakesunjavazictzdata）里找到了描述文件，翻到了伦敦的完整名称：“Europe/London”。

DaylightSaving

当我开心的在SimpleTimeZone中填入Europe/London作为构造参数后，启动发现服务器总是提示Timestamp不对，比对了一下之前使用new SimpleTimeZone(0, "GMT")这种方式传入的时间，总是晚1个小时：

通过百度查询发现，伦敦地区的时间确实就是6点54分呀，为什么要求的时区要提早一个小时呢？百思不得其解，浏览的各种时区网站后，发现了一个重要的问题：夏令时！

国外某些地区为了更好地利用白天的时间，会将时间延后1个小时或0.5个小时，当前伦敦正在处于夏令时状态，所以时间较UTC 0时区的时间会延后1个小时，而Timestamp这个参数只要求是UTC 0时区，忽略夏令时的特殊情况，那么直接使用TimeZone.getTimeZone("GMT+00")就可以拿到要求的UTC 0时区的时间了。