全球分为24个时区，相邻时区时间相差1个小时。比如北京处于东八时区，东京处于东九时区，北京时间比东京时间晚1个小时，而英国伦敦时间比北京晚7个小时（英国采用夏令时时，8月英国处于夏令时）。比如此刻北京时间是2017年8月24日11:17:10，则东京时间是2017年8月24日12:17:10，伦敦时间是2017年8月24日4:17:10。
既然Date里存放的是当前时刻距1970年1月1日0点时刻的毫秒数，如果此刻在伦敦、北京、东京有三个程序员同时执行如下语句：Date date = new Date();那这三个date对象里存的毫秒数是相同的吗？还是北京的比东京的小3600000（北京时间比东京时间晚1小时，1小时为3600秒即3600000毫秒）？答案是，这3个Date里的毫秒数是完全一样的。确切的说，Date对象里存的是自格林威治时间（GMT）1970年1月1日0点至Date对象所表示时刻所经过的毫秒数。所以，如果某一时刻遍布于世界各地的程序员同时执行new Date语句，这些Date对象所存的毫秒数是完全一样的。也就是说，Date里存放的毫秒数是与时区无关的。
可以看出，同一个Date对象，按不同的时区来格式化，将得到不同时区的时间。由此可见，Date对象里保存的毫秒数和具体输出的时间（即年月日时分秒）是模型和视图的关系，而时区（即Timezone)则决定了将同一个模型展示成什么样的视图。
每个地区都有自己的本地时间，在网上以及无线电通信中时间转换的问题就显得格外突出。我自己就经常混淆于此，特地研究了一下，记录在此以备忘。
整个地球分为二十四时区，每个时区都有自己的本地时间。在国际无线电通信场合，为了统一起见，使用一个统一的时间，称为通用协调时(UTC, Universal Time Coordinated)。UTC与格林尼治平均时(GMT, Greenwich Mean Time)一样，都与英国伦敦的本地时相同。在本文中，UTC与GMT含义完全相同。
北京时区是东八区，领先UTC八个小时，在电子邮件信头的Date域记为+0800。如果在电子邮件的信头中有这么一行：
说明信件的发送地的地方时间是二○○二年十一月八号，星期五，早上九点四十二分（二十二秒），这个地方的本地时领先UTC八个小时(+0800， 就是东八区时间)。电子邮件信头的Date域使用二十四小时的时钟，而不使用AM和PM来标记上下午。
即UTC是当天凌晨一点四十二分二十二秒。如果结果是负数就意味着是UTC前一天，把这个负数加上2400就是UTC在前一天的时间。例如，本地（北京）时间是 0432 （凌晨四点三十二分），那么，UTC就是 0432 - 0800 = -0368，负号意味着是前一天， -0368 + 2400 = 2032，既前一天的晚上八点三十二分。
在四月下旬，纽约又换用夏令时，又称为日光节约时，比标准纽约时间提前一个小时，实际成为西四区的标准时间，成为 -0400。
时区差东为正，西为负。例如，东八区（北京）是 +0800，西五区（纽约）是-0500，加州是西八区，是-0800，美国中部时区是西六区，-0600，美国山地时区是西七区，-0700，太平洋时区是西八区，-0800，在夏天使用夏时制，成为-0700。德国时区是东一区，+0100，夏天变为+0200。
多数电子邮件程序，例如Outlook Express，在显示时间时，计算机程序把时间先转换成为本地时间再显示，例如，邮件的Date域为：
Date: Thur, 07 Nov 2002 08:42:22 pm，把北京时间转换成为了纽约时间，而且把二十四小时格式的时间转换成为了十二小时的格式。当然，为了时间转换正确，发送方和接受方的计算机的时区都要设置正确，在这里，发送方的时区要正确地设为北京时区东八区，而我的时区要设为西五区。
在这里我们选择亚洲 Asia，确认之后选择中国（China)，最后选择北京(Beijing)
简单来说，ET在夏季月份（summer months) 采用EDT, 在其他月份采用EST时区，因此EDT和EST是不会同时存在的。
