澳大利亚时间 · 现在悉尼几点

打开就是悉尼那只走秒的大钟：当地时间、日期星期、此刻生效的英文缩写、比北京快几小时、是不是正在夏令时，旁边一只北京时间做参照。往下是「全国各时区现在几点」一览表（七支各自取一次时间，含两个半小时档）、南半球夏令时方向相反的说明卡与本轮起止、与北京时间的 24 行对照表、北京与当地互换、联系时段带，最后是各州首府现在几点。夏令时全交浏览器的时区库实时算，页面不写死任何日期。

怎么用

这一页只回答四件事：澳大利亚现在几点、和北京差几个小时、哪几个地方在实行夏令时、什么时候联系合适。从上到下七块，打开就能看，不用先选城市。

一、首屏那只大钟

最上面是代表时区的当地时间，走到秒。「澳大利亚时间」这个说法平时指的就是它——人口最多、也是大多数人要联系的那一头。钟面上还有四样东西：

• 此刻真正生效的英文缩写。写哪一个不是按月份猜的，是拿当前偏移与这支时区的标准偏移一比得出来的；
• 当地日期与星期，后面跟一句「与北京同一天」或者「已经是北京的明天」——澳大利亚在北京的东边，很多时候那边的日历已经翻页了；
• 与北京的时差，写成「比北京快多少」，后面跟着 UTC 偏移；
• 现在是夏令时还是标准时，正在实行夏令时时整只钟的边框会变色。

右边那只小钟是北京时间，做参照用，两只钟同时跳。

二、全国各时区现在几点

这是本页最花力气的一块：七支时区各一行，写明所属的大时区（东部／中部／西部）、时区中文名、当前生效的缩写、代表城市与所在州、IANA 时区名、此刻几点、与北京差多少、与代表时区差多少、以及今年这一支到底调不调钟。

有三个细节值得留意：

• 每一行的时刻都是按那一行自己的时区单独取的，不是拿代表时区加减几小时推出来的。同一个国家里的地方并不保证永远同步，推算迟早出错；
• 中部那两支是半小时档，表里会老老实实显示成半点，不会四舍五入成整点；
• 表头上方那一句会算出此刻全国最东与最西相差多久——这个数字一年里不是常数，实行夏令时的那几个月会被拉大。

点某一行的时区名，下面的对照表、换算、夏令时卡和联系时段带都会切到那一支。整张表也可以复制，出来是制表符分隔的纯文本。

三、南半球的夏令时，方向是反的

这是本页特意做出来的一块。北半球把钟往前拨的时候，澳大利亚东南部正把钟往回拨；等北半球拨回去了，这边又拨快。于是中澳之间的时差一年里会变，而且和中欧、中美之间的变法错开半年。

卡片里写清三件事：这边的夏令时落在年尾到年头（因为南半球的夏天在那段日子）；并不是全国都调，有几支时区常年不动钟；同一个国家内部因此会出现「半年同刻、半年差一个钟头」的情况。

卡片下面是当前那支时区的状态：现在是夏令时还是标准时、这一轮从哪天到哪天、跨不跨年、下一次调钟在哪天还剩几天、调完与北京的差从多少变成多少、缩写从哪个变成哪个。再往下是一份名单，写明今年扫下来哪几支会调钟、哪几支全年不动——这份名单同样是扫出来的，不是写在代码里的结论。

四、与北京时间对照表

选一支时区，直接给 24 行整点对照：北京 0 点到 23 点各自对应那边几点、是不是跨了日（标成「次日」）。当前这一小时会高亮，一眼能定位「现在在表的哪一行」。半小时档的时区，每一行都会正确地落在半点上。

表上方那句话把两个季节的数字一起给出来：现在差多少、另一个季节差多少——两个数字都是现算的，页面拿当年一月中旬和七月中旬各取一次这支时区的偏移比出来。表格可以整张复制，贴进表格软件或者聊天窗口都能用。

五、北京时间与当地时间互换

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

结果卡里除了两边完整的日期时刻，还给出当时的时差（注意是「当时」不是「现在」——填的日期如果在换季之后，用的就是新偏移）、跨不跨日，以及那一天该写的缩写。换季那两天的两件怪事页面都会明说：往前拨的那天当地有一小时并不存在，往回拨的那天有一小时出现了两次。

六、什么时候联系合适

一条 24 格色带，把北京的 9～22 点和当地的 9～22 点叠在一起：深色＝两边都清醒，浅色＝一边要将就，空白＝两边都在睡。上面一行是北京的钟点，下面一行是那一刻的当地钟点；右上角带小字的格表示那边还要再加半小时，带下横线的格表示已经是第二天。色带上方一句结论直接给出最值得推荐的那一段。

七、主要城市现在几点

各州首府与几座常去的城市按时区分组，每张卡上是当地此刻几点与当前生效的缩写。搜中文名、英文名或者州名都行；点一座城市，上面几块会切到它所在的那一支时区。

这一页不做的事

本页不向任何服务器要时间，显示的一切都是拿你这台设备的时钟加上时区偏移算出来的。设备时钟准不准，去时间校准量一下；查别的国家去世界时钟；看到 AEST、ACST、UTC+10 这类缩写不知道是几点，去时区缩写对照；要满屏大字的北京时间去北京时间。

怎么看结果

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

北京时间是 UTC+8 且全年不调钟，所以差值完全取决于澳大利亚那一侧此刻的偏移。页面的做法是拿当前偏移减去 480 分钟再写成人话，所以大钟、各时区表、对照表、换算结果四处的口径完全一致，不会互相打架。

要紧的是记住「中澳时差」不是一个数，而是一组数：按时区分三档，再按季节分两档。有人把某个记住的数字用一整年，结果在换季那几周把会议约错一小时——这是跨境协作里最常见的一小时误差。

三大时区与半小时档

澳大利亚本土常用的时区分三支：东部、中部、西部，彼此的差在标准时里是固定的；中部那一支是半小时档，也就是说它与东部相差的不是整小时。半小时时区在全球并不罕见，但很多网页时钟和日历软件处理得很糙，会把它显示成整点。本页从底层算起就用分钟当单位，对照表、色带、换算结果里的半点都是真的。

缩写为什么会变

同一个地方在实行夏令时和不实行夏令时的时候，英文缩写不一样：中间多一个字母的那个是夏令时写法。所以在邮件里写「下午 3 点 AEST」，有小半年是不准确的。

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

「同一个国家，两座城市不同时」

这件事在澳大利亚是常态，不是异常。因为要不要实行夏令时是由各州与领地各自决定的（以当地官方规定为准），于是每年有小半年，相邻两个州的钟会差开一个钟头。表现出来就是：

• 平时钟点一样的两座城市，某一天开始突然差一小时；
• 同一场跨州会议，两边的日历软件都显示「本地时间 10 点」，但其实差一小时；
• 全国最东与最西的差，也会随着季节被拉大。

页面那张各时区表里「与代表时区差多少」那一列，就是专门为这件事准备的：此刻是不是同一个钟点，看它一眼就知道。

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

澳大利亚在北京东边，大多数时候那边的钟点比北京靠前，深夜时段还会整天错开：北京晚上 11 点，东部那边已经是第二天凌晨。所以页面在四个地方都标了日期：

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

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

换季那两天

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

• 往前拨的那天，有一小时并不存在。换算里填了这么一个时刻，页面会提示并按拨过之后的时刻算；
• 往回拨的那天，有一小时出现两次。页面会提示并按第一次（夏令时那一次）给结果。

很多网页时钟碰到这两天会静默给出一个错一小时的答案，本页宁可多说一句。

时区算不出来的时候

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

常见问题

现在悉尼几点？这一页显示得准吗？

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

和那边的家人、同事打电话，几点合适？

用页面最下面那条色带。因为澳大利亚在北京东边且差得不算多，两边的作息重叠得相当好，常见结论是北京的上午到傍晚都能对上那边的白天，这一点比联系欧美轻松得多。需要注意的只有两件事：一是换季之后整段会挪一小时，别背结论、看当场算的那一句；二是发日历邀请时写清楚是哪一支时区或者直接写 UTC 偏移，别只写「10 点」。

上课时间、上班时间怎么对？

页面不提供任何学校或机构的具体作息表，那些各家各年不同，以对方公布的为准。能做的是把时刻换算这一层做准：用「换算」那一块把对方给你的当地时刻填进去，一眼看到对应的北京时间和是不是跨了日；要看一整天的对应关系，直接看 24 行对照表。

手机上能用吗？

能。窄屏下大钟会占满宽度，北京参照钟移到下面一行，各时区那张表会收掉「时区名」一列并允许左右滑动，城市卡变成单列，色带可以左右滑动。日期和时刻用的是系统自带的选择器。

为什么时区名写成「Australia/Sydney」这种样子？

这是 IANA 时区数据库的命名规矩：用「大区／代表城市」而不是国家或区域名。原因很实际——行政区划会变、一个国家也可能有好几支时区，而一座具体的城市相对稳定。所以堪培拉、黄金海岸这些城市在数据库里没有自己的条目，跟着各自的代表城市走。页面内部用的就是这些名字，表里也如实列出来，方便你写代码或者填系统设置时直接照抄。

页面为什么不做满屏大字的时钟？

那是另一页的活，本页专心做换算与时差这一层。要一块投屏用的大钟，去北京时间。

原理与冷知识

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

南半球的季节是反的，夏令时自然也跟着反。夏令时的本意是把夏天多出来的日照挪到傍晚，所以它永远跟着当地的夏天走。北半球的夏天在年中，南半球的夏天在年尾到年头，于是澳大利亚东南部的夏令时季跨年。这件事对写程序的人是个坑：不少现成的代码把「夏令时季」默认当成同一个日历年里的一段，套到南半球就会把起止配对错。本页专门为此做了一个跨三年的配对，并有单测钉住。

要不要实行夏令时，由各州与领地各自决定。这是澳大利亚时间制度里最特别的一点（具体以当地官方规定为准），结果就是同一个国家里既有会调钟的地方，也有常年不动钟的地方。好处是各地能按自己的纬度与作息选择，代价是国内协作多了一层换算——这也是本页把「与代表时区差多少」单独做成一列的原因。

半小时时区不是设计失误，是地理与行政折中的产物。当一个地方正好落在两个整小时时区的中间，取哪一边都别扭，于是折半。全球有若干个半小时甚至四十五分钟的时区，澳大利亚中部就是其中之一。对写程序的人来说，这条提醒很实在：时区偏移要用分钟存，不要用小时存；本页所有的算术都是按分钟来的。

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

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

「今天」在地球上不是一个瞬间。澳大利亚东部的日期换得比北京早，也早于欧美绝大多数地方；于是一场全球直播、一次版本发布、一个截止时间，在不同地方落在不同的日历日上。跨时区排班、结算与日志系统栽跟头，多半栽在日期而不是钟点上——这也是本页在四个地方都把日期标出来的原因。