万恶的 input，总有一天你会屈服的

前言介绍

input 作为表单元素的输入控件，承担着复杂而又繁重的角色。从文本到数字、网址、邮箱地址，再到单选、多选、滑动条，再到年月日时分，甚至于还有输入文件的功能，然而每一种类型都让人可爱可憎可恨。最近是跟这 type=date 系列杠上了，于是决定对它进行一番“批判”。

input 日期的种类

根据 w3school 中的介绍，一共就以下几种吧（都是 HTML5 中特有的类型）。

• date
• datetime
• datetime-local
• month
• week
• time

默认值的 Bug

input元素中支持同时显示日期和时间的类型为datetime、datetime-local两种，将yyyy-MM-dd hh:mm赋值给表单控件，类型为datetime的可以完美显示出来，但是类型为datetime-local就显示如下

The specified value "2018-08-09 20:54" does not conform to the required format.  The format is "yyyy-MM-ddThh:mm" followed by optional ":ss" or ":ss.SSS".

datetime在页面中显示就是一个纯文本框，想要页面出现日期时间选择的控件就必须使用datetime-local，但它默认是不支持yyyy-MM-dd hh:mm格式的时间的，那就想着把它转换成一个Date对象吧。在 PC 端浏览器是可以直接使用new Date()将其转换成一个Date对象的，而到了手机端，却像个失忆患者一样，拼命的告诉你转换的值为null。

在查询资料之后，发现移动端浏览器中的Date对象是不支持yyyy-MM-dd hh:mm这种格式的时间字符串，需要将其改变为yyyy/MM/dd hh:mm形式。然后在改变之后生成的值竟然和实际的值相差 8 个小时（对应当地东八区）：

const date = '2018/08/09 20:54';
new Date(date); // PC 端     2018/08/09 20:54
new Date(date); // mobile 端 2018/08/09 12:54

尝试着按照上面的提示将原时间字符串格式转换为yyyy-MM-ddThh:mm，就真的可以正确的给input元素添加默认值了。

HTML5 中new Date的时区

在上一节中，在移动端使用yyyy/MM/dd hh:mm的格式给进行Date对象实例化的时候，会出现生成的时间直接显示成 0 时区，继续摸索中又发现实例化出来的Date对象调用getHours函数时获取出来的小时数又是经过了当地时区转化的，因而能大致得出结论：移动端中Date对象生成的时间转换成字符串的时候是默认不带时区，时间对象本身的值还是没有问题的。
接下来，坑爹的事情来了。在页面中使用了datetime-local用于时间选择后，现在已经能够正常赋值了（前提是使用yyyy-MM-ddThh:mm格式），其实也理所应当的，选择时间后，返回的依然是yyyy-MM-ddThh:mm格式的时间字符串（依然是 0 时区），然后再将这个值转化成Date对象，返回的值比预想中要大了 8 个小时，没毛病，毕竟它显示的值就是 0 时区的，再转换回东八区时间就是加 8 个小时，但问题是 PC 端转换出来的值又是正确的，总有一方得妥协。毫无疑问，选择就是你了——移动端。

移动端取值、赋值的处理

以上已经能够了解移动端中input元素datetime-local类型的坑了，接下来就是解决方案。
首先是在赋值默认值的时候，将获取到的时间戳转换成yyyy-MM-ddTmm:hh格式的字符串（不能使用toISOString方法，该方法会返回 0 时区的值，导致字面上看起来又少了 8 个小时）。
然后再选择完时间之后，提交表单的时候将获得的yyyy-MM-ddTmm:hh格式的时间字符串将T替换成即可：

date.replace('T', ' ');

这样就能实现 PC 端和移动端兼容的input时间选择功能。

小结

HTML5 虽然发展到现在已经很不错了，但在input中的日期类型中还有一定的路要走。

附上博客传送门：https://blog.paddings.cn/2018/07/24/html/input-date/