洛杉矶时间 · 美西太平洋时间现在几点

打开就是洛杉矶那只走秒的大钟：当地时间、日期星期、此刻真正生效的英文缩写、比北京慢几小时、是不是正在夏令时，旁边一只北京时间做参照。往下是 PT 与两个季节写法的分辨卡、与北京时间的 24 行整点对照表、北京与洛杉矶互相换算、今年夏令时从哪天到哪天与下一次调钟，以及一条把两边作息叠在一起的联系时段带；最后列出旧金山、西雅图、拉斯维加斯一类同一刻的城市。夏令时全部由浏览器的时区库实时算，页面不写死任何日期。

怎么用

这一页只回答四件事：洛杉矶现在几点、和北京差几个小时、该写 PST 还是 PDT、什么时候联系合适。从上到下七块，打开就能看，不用先选城市。

一、首屏那只大钟

最上面是洛杉矶当地时间，走到秒。钟面上还有四样东西：

• 此刻真正生效的英文缩写（PST 或 PDT）。写哪一个不是按月份猜的，是拿当前偏移与这个时区的标准偏移一比得出来的；
• 当地日期与星期，后面跟一句「还是北京的昨天」或者「与北京同一天」——跨半个地球最容易错的其实是日期，不是钟点；
• 与北京的时差，写成「比北京慢多少小时」，后面跟着 UTC 偏移；
• 现在是夏令时还是冬令时，正在实行夏令时时整只钟的边框会变色。

右边那只小钟是北京时间，做参照用，两只钟同时跳。上面一个下拉可以把全页读数在 24 小时制与 12 小时制（上午／下午）之间切换——外国同事发来的时间常写成「6 PM」，切到 12 小时制对起来更直观。这个选择会记在你这台设备上。

二、PT、PST、PDT 分辨卡

三张并排的卡，各写清楚英文全称、中文名和什么时候该用它，此刻真正生效的那一张会高亮，另外两张标成「现在不生效」或「任何时候都能写」。

卡片下面那一行是与美东的差：页面拿洛杉矶和纽约两地各取一次当前偏移比出来，所以这句话在任何季节都是对的。

三、太平洋时间与北京时间对照表

选不用选，直接给 24 行整点对照：北京 0 点到 23 点各自对应洛杉矶几点、是不是跨了日（标成「前一日」）。当前这一小时会高亮，一眼能定位「现在在表的哪一行」。

表上方那句话把两个季节的数字一起给出来：现在差多少、另一个季节差多少——两个数字都是现算的，页面拿当年一月中旬和七月中旬各取一次这个时区的偏移比出来。

表格可以整张复制，出来是制表符分隔的纯文本，贴进表格软件或者聊天窗口都能用；切到 12 小时制时复制出来的也是 12 小时制。

四、北京时间与洛杉矶时间互换

填一个日期和一个时刻，点「换算」看对面几点。方向可以选「北京时间 → 洛杉矶当地」或者反过来，「对调」一键换向，「现在」把日期时刻填成此刻。

结果卡里除了两边完整的日期时刻，还给出当时的时差（注意是「当时」不是「现在」——填的日期如果在换季之后，用的就是新偏移）、跨不跨日，以及那一天该写的缩写。

换季那两天的两件怪事，页面都会明说：春天拨快的那天当地有一小时并不存在，秋天拨回的那天有一小时出现了两次。很多网页时钟碰到这两天会静默给出一个错一小时的答案。

五、夏令时卡

这一块回答「今年的夏令时从哪天到哪天」「现在是夏令时还是冬令时」「还有多久调钟」「调完差几小时」。上面写着当前状态与偏移，下面列出今年拨快与拨回的两个日期（连当地几点跳到几点一起给）、下一次调钟的日期与还剩几天，以及调完之后与北京的时差从几小时变成几小时、缩写从哪个变成哪个。

六、什么时候联系合适

一条 24 格色带，把北京的 9～22 点和洛杉矶的 9～22 点叠在一起：深色＝两边都清醒，浅色＝一边要将就，空白＝两边都在睡。上面一行是北京的钟点，下面一行是那一刻的洛杉矶钟点，带下横线的格表示那边还在前一天。色带上方一句结论直接给出最值得推荐的那一段。

七、同一时刻的其它城市

旧金山、圣迭戈、圣何塞、西雅图、波特兰、拉斯维加斯与洛杉矶共用同一套时区规则，钟点永远一样；温哥华和蒂华纳在别的国家，页面按它们自己的时区各取一次，并如实标出此刻是不是和洛杉矶同一个钟点——这两个地方的调钟规则由各自的国家决定，不能假设永远同步。

这一页不做的事

本页不向任何服务器要时间，显示的一切都是拿你这台设备的时钟加上时区偏移算出来的。设备时钟准不准，去时间校准量一下；要把美国六个时区摆在一屏去美国时间；要美东去纽约时间；查别的国家去世界时钟；看到 EST、CST、UTC+8 这类缩写不知道是几点，去时区缩写对照。

怎么看结果

「比北京慢几小时」是怎么算出来的

北京时间是 UTC+8 且全年不调钟，所以差值完全取决于洛杉矶那一侧此刻的偏移。太平洋时区在实行夏令时时是 UTC−7，比北京慢 15 小时；其余时间是 UTC−8，慢 16 小时。同一个「中美时差」一年里有两个数，变的不是北京，是美国那一边。

页面的做法是拿当前偏移减去 480 分钟再写成人话，所以钟面、对照表、换算结果三处的口径完全一致，不会互相打架。

缩写为什么会变：PT、PST、PDT

同一个地方一年里换两次名字。很多人把「美西时间」直接等同于 PST，于是在实行夏令时的那几个月里算错一小时——这是跨境沟通里最常见的一小时误差。

避免出错有三个办法：写不分季节的 PT；直接写 UTC 偏移；或者干脆贴一个具体时刻的换算结果，把歧义消掉。页面钟面上的缩写不是按月份判断的：拿当年一月中旬与七月中旬各探一次偏移，小的那个当作标准时，当前偏移比它大就说明正在夏令时，于是显示 PDT。这个做法不依赖任何写死的日期，规则将来改了也不会错。

太平洋时间覆盖哪些地方

大致是加利福尼亚州、华盛顿州、俄勒冈州与内华达州大部分地区，代表城市是洛杉矶、旧金山、圣迭戈、圣何塞、萨克拉门托、西雅图、波特兰、拉斯维加斯。日常说的「加州时间」「美西时间」「硅谷时间」，指的基本都是这一个时区。

🔴 时区边界不是按州切的。美国有若干个州内部跨两个时区，本页只给城市、不逐州下结论；要确认某个具体的小地方，以当地官方或者对方本人说的为准。

跨日：比几点更容易错的事

北京和洛杉矶差十五六个小时，两地有大半天日期对不上：北京周一上午 9 点，洛杉矶还是周日下午 6 点。所以页面在四个地方都标了日期：

• 大钟下面写着与北京是不是同一天；
• 对照表第三列专门标「前一日／同一天」；
• 换算结果里跨日会标成「次日」或「前一日」；
• 联系时段带里洛杉矶那一行，属于前一天的格子带下横线。

约会议、发邮件、定截止时间时，先看日期，再看钟点。

换季那两天

一年有两天，当地的墙上时间会出问题，本页都老实标出来：

• 春天拨快的那天，有一小时并不存在。当地 2:00 直接跳到 3:00，「2 点 30 分」那天压根没有。换算里填了这么一个时刻，页面会提示并按拨快之后的时刻算；
• 秋天拨回的那天，有一小时出现两次。当地 2:00 拨回 1:00，于是「1 点 30 分」当天来了两遍，页面会提示并按第一次（夏令时那一次）给结果。

还有个连带效应：欧美的调钟日期并不在同一天，每年春秋各有一两周，一边已经调了而另一边还没调，欧美之间的时差会临时变一小时。中美之间不存在这个问题——中国不调钟，所以变化只来自美国这一侧。

时区算不出来的时候

极老的浏览器或者被裁剪过的运行环境可能没有完整的时区库，这时页面顶部会出现一条红色提示，全页退回「固定偏移、不含夏令时」的估算。这种情况下，实行夏令时的那几个月里显示的洛杉矶时刻会比实际慢一小时，结论仅供参考——换一个现代浏览器就好了。

常见问题

现在洛杉矶几点？这一页显示得准吗？

时区换算这一层是精确的：夏令时、跨日、换季那两天全都算对。但整体准不准取决于你设备的时钟——页面是拿设备的当前时刻加上时区偏移算出来的，本身不向服务器要时间。开着自动对时的手机和电脑通常在一秒以内；要确认可以去时间校准量一下偏差。

「太平洋时间下午 6 点」是北京几点？

把页面上的下拉切到 12 小时制，方向选「洛杉矶当地 → 北京时间」，日期填当天、时刻填 18:00，点「换算」就有答案，并且会告诉你北京那边是不是已经到了次日。想看一整天的对应关系，直接看上面那张 24 行对照表。之所以推荐用页面算而不是背一个数，是因为答案在换季前后会差一小时。

加州时间、美西时间、硅谷时间是同一个时间吗？

在钟点上是同一回事，都是太平洋时间。加州全境使用同一个时间，所以洛杉矶、旧金山、圣迭戈、圣何塞、萨克拉门托显示的时刻完全一样；西雅图（华盛顿州）、波特兰（俄勒冈州）、拉斯维加斯（内华达州）也在这个时区里，钟点同样一致。页面最后那一块就是按这个逻辑列的。

和硅谷的公司开会，几点合适？

用页面最下面那条色带。常见结论是：北京上午到下午早些时候，对上洛杉矶的傍晚到晚上；反过来，洛杉矶上班时间对应的是北京的深夜到凌晨。所以跨太平洋协作通常有两种排法——要么中国这边下午、对方晚上，要么中国这边早上、对方前一天下班前。色带会把每一小时都标出来，换季时整段会挪一小时，别背结论，看当场算的那一句。另外记得在邀请里写清楚是 PT 还是北京时间，日历软件才不会把与会者拖错一小时。

温哥华、蒂华纳为什么单独列？

因为它们不在美国。加拿大和墨西哥的调钟规则由各自国家决定，历史上也各自改过。虽然目前这两座城市的钟点与洛杉矶一致，但页面不假设这件事永远成立——它们各按自己的 IANA 时区取一次时间，并如实标注此刻是不是同一个钟点。这也是写跨时区程序时的通用原则：别把「现在一样」当成「永远一样」。

手机上能用吗？

能。窄屏下大钟会占满宽度，北京参照钟移到下面一行，缩写卡与城市卡变成单列或两列，对照表会收掉「日期」那一列（跨日信息在换算和色带里仍然看得到），色带可以左右滑动。日期和时刻用的是系统自带的选择器。

为什么时区名写成「America/Los_Angeles」？

这是 IANA 时区数据库的命名规矩：用「大区／代表城市」而不是国家或区域名。原因很实际——行政区划会变、一个国家也可能有好几个时区，而一座具体的城市相对稳定。太平洋时间在数据库里就叫 America/Los_Angeles，温哥华与蒂华纳各有自己的名字。页面内部用的就是这些名字。

原理与冷知识

时区数据是一份全球共同维护的文件。浏览器、手机、服务器里那份时区规则叫 IANA 时区数据库（也叫 tz database），记录了每个地区的偏移变化、夏令时规则与历史调整，一年发布好几个版本。这也是网页不该自己写夏令时日期表的根本原因：写死的那一刻就开始过期。本页把这件事完全交给这份数据库——连「今年从哪天到哪天」都是逐日扫偏移扫出来的，再在变化的那一天里二分到分钟，所以能精确说出「当地 2:00 跳到 3:00」。

美国的时区是铁路划出来的。十九世纪中叶以前，每座城市各用各的太阳时，相邻城镇差几分钟没人在意。铁路来了之后时刻表成了灾难：一列车沿途每一站都要换算当地时间。1883 年 11 月 18 日，北美各铁路公司自行统一划出四个标准时区，那一天被称为「两个正午的一天」——很多城市的钟在中午被重新对了一次。国会直到 1918 年才把这件事写进法律。也就是说，美国的四个时区先由企业定下，政府后来才追认，太平洋时间是其中最西的一个。

夏令时最初的理由是省照明电，今天的研究普遍认为这点节约非常有限，反而带来切换前后的作息紊乱、交通事故与软件故障。美国历史上多次改动起止日期，也做过全年夏令时的尝试。近年不断有取消调钟的提案，但卡在一个老问题上：取消之后到底全年用标准时还是全年用夏令时，各方谈不拢。所以它的存废更多是协调问题，不是技术问题。

「日期变更线的另一边」是这条时区带最直观的体验。北京与洛杉矶差十五六个小时，意味着一天里有很长一段两地连日期都不同。有个常被用来解释时差的说法：从洛杉矶起飞往西飞越太平洋，落地时日历会往前跳一天；往东飞回来，则可能「同一天到达两次」。跨时区排班、结算与日志系统栽跟头，多半栽在日期而不是钟点上。

为什么系统内部一律存 UTC。跨时区的先后关系要能比较，就不能各记各的。通行做法是：内部只存 UTC 或 Unix 时间戳，只在显示给人看的那一刻才套上时区。本页也是这么算的——先把你填的当地时刻反解成 UTC，再折算到另一边。反解这一步比正向难，因为存在「不存在的一小时」和「出现两次的一小时」，所以要先按标准偏移猜一次，用时区库校正，再验一遍墙上时刻对不对，对不上才知道撞上了换季那天。想看时间戳本身长什么样，去时间戳转换。

美西与美东的 3 小时是同步调钟的结果。两个时区一起拨快、一起拨回，所以它们之间的差全年不变；而不调钟的地方就不一样了——比如亚利桑那州大部分地区常年不动，夏天它与洛杉矶同刻、冬天又与丹佛同刻。这说明一件事：「两地差几小时」不是一个常数，而是一个关于时刻的函数，本页所有的差值因此都是按当下算的，没有一个写死在代码里。

北京时间一个时区，横跨约 60 个经度。与美国划四个时区的思路相反，中国全境统一使用北京时间（UTC+8），法定上只有一个时区，也没有夏令时。好处是全国的时刻表、通讯、调度不必换算；代价是西部作息与太阳错位。这也正是本页把北京时间当作固定基准线的原因：它一年到头不动，中美时差的所有变化都来自太平洋那一头。