标签: JS

Javascript 的时间格式问题

先上代码:
再说结论:

在 Javascript 中,当为某个变量只赋值日期时,会默认使用该日期的 0 点 0 分 0 秒作为完整的值。而根据表现格式的不同,在具体赋值时会使用不同的时区时间赋值。

当使用『-』作为年月日的分隔,即 YYYY-MM-DD 的格式时,赋值会根据 GMT/UTC 时间的当日 0 点赋值,再根据浏览器提供的系统时间,折算为当地时间。也就是说,如果你在北京,并且电脑时区正常。那么当你为某变量赋值『今天』时,实际上赋的值是 0 时区的 0 点 0 分 0 秒,换算成北京时间为早上 8 点。如果在东京,则是早上 9 点。

也就是说,无论是在哪个时区,相同的一套代码在不同的电脑上,会得到相同的值。

 

而当使用『/』作为年月日的分隔,即 YYYY/MM/DD 的格式时,赋值则根据电脑时间,取到本地时间该日的 0 点 0 分 0 秒。由于各时区都差一个小时整,实际上会导致 JS 代码在不同时区电脑上执行相同代码时,得到的时间值在绝对值上并不相等。即在北京时区时,会取到北京时区的 0 点 0 分 0 秒,同一时刻在东京则已经是当日 1 点 0 分 0 秒了。

换句话说,不同客户端执行相同代码会取得不同的值。

 

但即使如此,两者也有表现相同的时候。只要在赋值时就明确指定时区,则两者的值可以是相同的。例如:

同时,无论是哪种情况,当通过 JS 转换成时间戳时,其值都是相同的。原因在于时间戳本身的定义,就是指当前时间距 0 时区的 1970 年 1 月 1 号 0 点 0 分 0 秒的秒数。所以在执行环境中,函数会根据电脑的时区设置来加减相应的小时数,先转换为 0 时区,然后再进行时间距离的计算。

参考:

http://www.w3schools.com/js/js_date_formats.asp

今天学习了 DOM 事件流三阶段

起了个小学生式标题。

这东西又是浏览器历史的一桩恩怨……当最初的 HTML 标记式的语言结构逐步成形后,人们开始对网页内的互动有了要求。当然,这事本来并不难,所有的用户互动归根结底就是『触发事件 – 判断当前状态 – 执行相应命令』的逻辑,而 HTML 本身就已经通过开标签和闭标签组对的形式,很好地形成了后来被称之为『DOM 元素』的数据结构,理论上只要把触发事件分别加到一个个的元素上,或者按需加到某些特定的元素上,就可以执行命令了。

然后问题就来了。

由于 HTML 的表现是盒式结构,都是一些大框框包含小框框的情况。比如如下代码:

形成的 DOM 盒式包含结构大约就是这样:

无命名

当用户点击红块时,实际上浏览器是无法判断这次点击的意图的,也就是说,到底应该是点在红块上,红块对这次点击作出反应,还是点在绿块上,亦或是蓝块上。即使是三者都算作被点到了,三者都有反应,那怎么也得有个先后顺序吧。

有两种顺序都可以,一种是先子后父,先里后外,红绿蓝顺序;第二种是先父后子,先外后里,蓝绿红顺序。

两者都可以,两者都有理,然后老 IE 用的是前者,老 Netscape 用的是后者……结的梁子够多了,也不差这一个了。

于是新的协议为了兼容,提出了 DOM 事件流的三个阶段的设计,即……首先,都别争了,顺序就按『蓝绿红绿蓝』这么来吧……然后,这一顺序又分成三个阶段,第一阶段我称之为『下沉』,顺序为蓝绿;第二阶段『触底』,系统发现红色已经是最底层 DOM 元素了,第三阶段『上浮』,顺序变成了红绿蓝。

这三个阶段是有标准的命名的,分别是『捕获阶段』、『目标阶段』、『冒泡阶段』。并且严格来说,捕获阶段不包括最底层元素,而冒泡阶段包括目标阶段。盗图一张:

001108_Ry8q_214423

尽管规范上来说,要求捕获阶段只注册事件,而在冒泡阶段执行相应阶段。但事实上各浏览器在实现时,都允许在捕获阶段也执行相应的事件。结果就是,对于一个目标,有两次执行事件的机会。这在为 DOM 元素添加事件的 JS 函数里就写得很明白:

其中第三参数就是决定这个事件是否在捕获阶段就开始执行的。

当我们使用 jQuery 等第三方库时,这一特性被 jQuery 很好地隐藏封装起来了,并良好地处理了各浏览器不一致的特性,使得我们可以通过 .click() 函数方便地添加点击事件,并不用考虑三个阶段的问题。