笔记分成两部分：1、与 UTC 相关的一些概念的理解；2、JavaScript 里的 Date 类型
在引用中文维基百科基础上，加一点自己对此的理解，介绍一下 UTC 以及与之相关的一系列其他的术语的概念：时标、UT、TAI、GMT，希望能通俗易懂的同时也不至于缪人千里（有错误的地方欢迎指正）：
- 时标：时标指的是一种将时间分配到事件的机制，通过某些事件的发生我们可以确定对应的时间。现时有两类时标被广泛应用，一种是「基于天文学」的，这个我们可能比较熟，比方说现在时间是 2018 年 7 月 24 日 12 点整，太阳在我们正头顶，等到下一次太阳在我们正头顶的时，那我们知道这个时候距离上次过了一天，时间应该就是 2018 年 7 月 25 日 12 点整；另一种是基于「原子振动频率」的，也举个例子，比如我们知道某个原子振动发生跃迁辐射 XXX（某个整数） 个周期的时间刚好是 1 秒，现在时间是 2018 年 7 月 24 日 12 点整，我们让这个原子开始振动，并开始记录，当记录振动了 XXX * 3600 个周期后我们可以知道这个时候距离刚才过了 1 个小时，那么此时时间就是 2018 年 7 月 24 日 13 点整。下面说的 UT、GMT、TAI、UTC 都是一种时标。后面相关的内容基本出自中文维基百科。
- UT（Universal Time，世界时）：是一种以格林尼治子夜起算的平太阳时。世界时是以地球自转为基准得到的时间尺度，其精度受到地球自转不均匀变化和极移的影响，为了解决这种影响，1955年国际天文联合会定义了UT0、UT1和UT2三个系统：
- UT0 系统是由格林尼治天文台的天文观测直接测定的世界时，没有考虑极移造成的天文台地理坐标变化。该系统曾长期被认为是稳定均匀的时间计量系统，得到过广泛应用。
- UT1系统是在UT0的基础上加入了极移改正 Δλ，修正地轴摆动的影响。UT1是目前使用的世界时标准。被作为目前世界民用时间标准UTC在增减闰秒时的参照标准。
- UT2系统是UT1的平滑处理版本，在UT1基础上加入了地球自转速率的季节性改正 ΔT。
- GMT（Greenwich Mean Time，格林尼治平时）：格林尼治平时的正午是指当平太阳横穿格林尼治子午线时（也就是在格林尼治上空最高点时）的时间。由于地球每天的自转是有些不规则的，而且正在缓慢减速，因此格林尼治平时基于天文观测本身的缺陷，已经被原子钟报时的协调世界时（UTC）所取代。GTM 可以看成与 UT0 一回事。
- TAI（International Atomic Time，国际原子时）：是根据以下秒的定义的一种国际参照时标，属于国际单位制。
秒的定义：1967年第13届国际计量大会上通过一项决议，定义一秒为铯-133 原子基态两个超精细能级间跃迁辐射 9,192,631,770 周所持续的时间。其起点为世界时1958年的开始。就是说，铯-133 原子基态两个超精细能级间跃迁开始辐射这件事发生，到它们辐射上面那么多周期这件事发生时，这两件事发生的间隔的度量就定义为 1 秒的长度。 - UTC（Coordinated Universal Time，协调世界时）：协调世界时是世界上调节时钟和时间的主要时间标准。基于国际原子时，并通过不规则的加入闰秒来抵消地球自转变慢的影响。闰秒在必要的时候会被插入到 UTC 中，以保证协调世界时（UTC）与世界时（UT1）相差不超过0.9秒。就是说现在日常生活中我们都是以这个时间为准的，比如我们戴的机械表可能会找手机或者电脑上的时间来对，那手机、电脑上的时间又是怎么来的呢？在联网的时候，手机和电脑会定期向系统预置的某个服务器地址请求时间同步，而这些服务器的提供的时间就是 UTC 时间。既然定义了 1 秒的确切度量，引入了 TAI 这个十分精确可靠的时标之后，为什么还要有 UTC 呢？我想应该是因为如果只追求精确而不顾按天文台实际测量的时间的话，时间一久 TAI 和 UT1 两个时间标准的间隔就会越来越大，比如，按以往经验太阳在正头顶的时候应该是 12 点，而实际上 TAI 告诉我们时间已经 13 点。所以就协调出这么一个 UTC 时间，使得其在 TAI 的基础上，通过必要时加入闰秒来保证与 UT1 的间隔不超过 0.9 秒，同时又可以保持与 TAI 的联系：TAI - UTC = N * SI 秒。这个 N 就是实行「加闰秒」这个机制以后在 UTC 上所加的闰秒的总数（根据中文维基百科最后一次闰秒是 2016 年的最后一刻，那是迄今为止加的第 37 秒，所以这里的 N 就是 37）。加闰秒是什么意思呢，跟闰二月一样，闰二月有 29 天，加入了闰秒的那一分钟会有 61 秒，即如果你的电脑和手机的系统支持闰秒的话，那天在 23:59:59 之后会有 23:59:60，然后才是第二天的 00:00:00。
对应引用：
- http://www.weather.gov.hk/gts/time/basicterms-timescaleofmeasurement1c.htm
- https://zh.wikipedia.org/wiki/%E5%8D%8F%E8%B0%83%E4%B8%96%E7%95%8C%E6%97%B6
总而言之， UTC 就是一个现今被人们广泛参考并使用的时标。
下面简单介绍 Date 对象。Date 类型是 JavaScript 里内置的引用类型，使用自 UTC 1970 年 1 月 1 日子夜开始经过的毫秒数来保存日期。首先，它是一个函数，作为构造，接受的参数类型有：
- String：可以表示日期的字符串，其实此时是在后台先调用 Date.parse(String) 后再将赶回的结果传给 new Date()
- int|String[, int|String[, int|String...]]：表示年、月、日、时、分、秒的数字或对应字符串，此时是在后台对传入的参数调用 Date.UTC() 然后再将结果传给 new Date()
- Date：也可以直接传入一个 Date 类型的对象，相当于重新 copy 一个相同的 Date 对象
作为普通函数，不管传入什么值，统一返回本地当前时间对应的字符串，即 new Date().toString()。
下面介绍下 Date.parse() 和 Date.UTC()：
- Date.parse()：parse() 接受一个表示日期的字符串参数，然后尝试根据这个字符串返回相应日期的毫秒数，字符串的格式官方没有统一规定，通常因地区而异。这里需要注意的是，虽然 new Date() 返回的对象的 toString() 方法返回的是表示当地时间的字符串，但是 Date.parse() 返回的毫秒数是时区 0 对应时间的毫秒数，比如在 GMT+8 时区调用 Date.parse('1970-1-1') 按理返回的是 0，但是实际上返回的是时区 0 对应时间的毫秒数 -28800000（刚好等于 8 * 3600 * 1000）。此外另一个需要注意的是，iPhone safari 浏览器上在 Date.parse() 上 调用类似 '2012-12-12 12：12' 这样格式的参数时，会返回 NaN，所以对应的 new Date() 也会返回 'Invalid Date' 的信息。此时可以通过把字符串解析成一个数组 arr，然后调用 new Date(...arr) 就可以
- Date.UTC()：UTC() 接受多个表示年、月、日、时、分、秒的数字或对应字符串，其中第一个表示年份的参数是必须的，后面的默认为 0，且月份的范围为 0 到 11；与 parse() 不同的是，它返回的是本地时间所对应的毫秒数，就是说 Date.UTC(1970, 0, 1) 返回的就是 0。
Date 类型重写了 Object 对象，toString、toLocaleString、valueOf 三个方法，前两个方法都返回当前日期对应的字符串，但前者是带 GMT 信息的，后者返回带上下午信息的本地时间； valueOf 方法返回的是日期对应的毫秒数。因此对于两个 Date 对象可以直接进行「比较」操作和「减法」操作，但是不能直接调用「加法」操作，因为「加法」的操作数是 Object 类型时，是先调用其 toString() 方法，此时的结果会是两个字符串相加。需要 (+date2) + (+date2) 才可以。
getUTCHours() 和 getHours()，带 UTC 和不带 UTC 的区别是前者赶回的是转换成时区 0 的日期，后者是本地日期，建议在做运算时统一使用时区 0 的日期，待需要展示的之后再转换成本地日期。
对应操作日期的库，moment 和 dayjs，moment 很强大，比如各种各样的格式化、日期 add 和 substract等，但是有时候可能太重了，这时候可以用 dayjs 这个稍轻量一点的库，api 一样，功能基本不差。
