这个问题可能在日常中不太可能遇到，但是在处理一些国际化的项目中可能会涉及。例如当你浏览一些推特或者国外的论坛，它们会标记所在的时区是什么，在什么时候发布。
考虑一个真实的场景，如果你要定时发布一个文章，可能希望在 12 月 11 日的 12 点发布，采用纽约时间，但是因为你所在中国可能并没有考虑到时区带来的差异，直接导致这篇文章提前发布了。
在下面文章正式开始之前需要补充一些遗忘的高中地理知识，地球是自东向西自传的，所以东半球总是先于西半球。从本初子午线往东，每次增加一个时区则+1，而从本初子午线往西每个时区-1。因为中国属于东八区，所以我们是+8。
而下面文章会涉及到 UTC 的一些知识，你只需要简单理解 UTC 在大多数情况下（不涉及到秒）跟之前的格林威治时间（GMT）相同。而 GMT 就是规定了每天太阳经过格林尼治皇家天文台的时间为中午时间点。
而本初子午线的别称就是格林尼治子午线。
你可能还会疑惑本初子午线是什么，其实就是 0 度经线，经线就是从上往下的一条线，本初子午线会经过英国、法国、西班牙、阿尔及利亚、马利、布基纳法索、多哥和加纳共 8 个国家，然后直至南极。
更多内容可能查看 本初子午线
而且很多国家并没有统一时区，例如美国从东(大西洋的海岛)到西(太平洋上的小岛)，又有分为九个时区(包括海洋部分)。如果再配合美国的夏时制实施与否，可以复杂到十几个不同的时间。
始皇帝国外在呼唤你！
那么在实际开发中作为前端要怎么来处理时区带来的问题呢？
回到开头所举例中，js 的 Date.now 默认取的是当前计算机的时间，这个时间是可以被用户手动修改的。而且当用户手动选择一个日期，例如 2025-11-11 23:00:00 这个时间，在不同的时区进行格式化得到的时间戳一定是 1762873200000 因为这个时间戳表示的是从 1970 年 1 月 1 日 00:00:00 (UTC) 到该时间点的毫秒数。
那么有什么方法可以规避让时区带来的影响呢？
Intl.DateTimeFormat
Intl.DateTimeFormat 象能使日期和时间在特定的语言环境下格式化。
其中可以调用 Intl.DateTimeFormat().resolvedOptions().timeZone 来获取客户端所在的时区。 上面代码会输出 Asia/Shanghai。
获取与 UTC 的偏移时差可以通过 new Date().getTimezoneOffset() 完成，上面这段代码会输出 -480 单位是分数，而根据上面的科普我们知道 0 - (-8) 就是+8，刚好表示东八区。
IP 地址
也可以通过 http 协议来获取用户的大概位置，例如在访问一些网站的时候，它会默认把语言切换到你所在的 ip 位置。
至于如何获取 ip 位置，通常会从报文 X-FORWARDED-FOR、X-FORWARDED-FOR 等字段来读取。
自行选择
如果上面的方式都无法解决，可以尝试给用户自己选择区域的机会，就像是爬虫或者外挂的攻防，解决不了问题就解决提出问题的人。
最后
如果文章写的有错误欢迎指出 👏。
参考：