js时间戳转换成年月日时分秒_js之时区转换

点击蓝字关注我

写在开头的话

      时区转换这个知识点对于大部分开发者来说其实用到的几率无限接近于零。但是总有那么一小部分开发者狗血的要在这个点上多做深究。至于为什么，，，怎么说呢，这可能要去问候一下公司产生这个需求的人了。。。

时区问题之地理

      相信小伙伴们都学习过地理知识。其中地理有讲到地球分为24个时区，每个时区都有自己的本地时间。

      在国际无线电通信场合下为了统一起见，使用一个统一的时间，称为通用协调时(UTC,Universal Time Coordinated)。

除了UTC时间还有一个GMT时间。GMT时间是格林尼治平均时。UTC和GMT时间一样都与英国伦敦的本地时间相同。

      UTC时根据原子钟来计算时间。

     GMT是根据地球的自转和公转来计算时间，也就是太阳每天经过英国伦敦郊区的皇家格林威治天文台的时间就是中午12点。

      世界上最精确的原子钟计算每50亿年才会有1秒钟的误差。而由于地球的自转在不断的缓速变慢，所以在相对50亿年内肯定有一天本应该是中午12点的时候，实际上却是早上或者晚上。

      所以UTC比GMT时间更加精确，但是在误差允许的范围内可以认为他们俩是相等的。

      tip：顺便说一下，UTC时间是从1970年1月1日的午夜零时零分零秒开始计算的。

时区之Date类型

     相信无论是后端开发者还是前端开发者，对于Date这个时间构造函数应该都不陌生。

     要创建一个日期对象，使用new操作符和Date构造函数即可：var date = new Date()

     这种方式会生成一个本地时区的时间对象。通过Date类型的方法我们可以获取到具体的年份，月份，几号，几时几分几秒几毫秒，这时我们获取到的时年月日时分秒是我们执行这个代码的地理位置的时间。在同一时间的不同时区执行这个代码所得到的值是不一样的。

时区之需求

      因公司的业务人员遍布全球，并且存在同一个人可能固定在某个时区工作，但存在临时调去或者长期调去其他时区工作的可能性。每个人的时区由后台设置。

      所以在该系统的实现时，对于单据，任何的新增，修改，更新时间都要以该用户身上设置的时区进行换算。

      打个比方：小明是我司的一名业务，在东八区工作，有一天临时调到西八区工作。当他在西八区创建单据或者相关的表单数据时，系统要认为他是在东八区工作，时间在页面显示时要按照东八区的时间显示。

时区之实现

      这个需求听起来可能会有些让人头晕，没错，小编当初也是第一次遇到这样的需求，我们的后端开发人员也是第一次遇到，所以当初我们是周六日两天连续通宵才把这个问题彻底搞定，当然还附带了其他的问题。

      回到实现上来说。我们再用实际时间来说一下上面说的例子：

      假如小明在西八区的中午十二点生成了一个单据，当小明回到东八区后再看这个单据时显示的时间依然是中午十二点。

      其中，服务器无论在哪个国家我们设置的本地时区都是零时区，也就是说服务器端保证了是零时区。

      因为系统是包含前后端，当后端保证了是零时区后，我们要操心的问题就是前端了。前端在生成一个时间的时候也就是通过new Date().getTime()生成当前时间点的零时区时间戳，此时我们拿到的是真正的零时区时间戳，我们只需要把这个时间戳传给后端即可。

      而当后端传给我们的时候，我们把这个时间戳加上用户身上的时区再通过Date类型的相关方法生成年月日时分秒，这样就完成了该需求。

      在实际中逻辑比这个又复杂了点，但是基本原理思路是一样的，需求是千变万化的，但是真理只有一个，掌握真理，便可一夫当关万夫莫开的应对所有问题了。

      如果有小萌新不知道Date类型的方法的，就访问这个连接吧：https://www.w3school.com.cn/jsref/jsref_obj_date.asp

写在结尾的话

      如果有不明白的地方或者由逻辑不对的地方欢迎私聊小编哦。

      下期预告：eslint Or koa2为之前用react写的todolist写一个后端服务。