Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: =?UTF-8?B?QmrDtnJu?= Persson <Bjorn@xn--rombobjrn-67a.se>
Newsgroups: comp.lang.ada
Subject: Re: Ada Monthly Meetup, 7th of March
Date: Sun, 22 Feb 2026 11:49:40 +0100
Lines: 44
Message-ID: <20260222114940.1d660ac0@tag.xn--rombobjrn-67a.se>
References: <10nbsn5$14ahv$1@dont-email.me> <20260221201013.1e8b665b@tag.xn--rombobjrn-67a.se> <10nd7m8$1jipc$3@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Trace: individual.net 0sOEijhssHRP9zFOiy7w6gYEL+BCIAM4w3vL9W5g+wWhWsjbXa
Cancel-Lock: sha1:Ga6XClmjYuRp0Kk8ZoXENeil6a4= sha256:6m0LcV1MSrLxcE/af+K2VDfl9SCV/PkwmaoauX+/XO4=
X-Newsreader: Claws Mail 4.3.1 (GTK 3.24.49; x86_64-redhat-linux-gnu)
Xref: csiph.com comp.lang.ada:59664

Lawrence D=E2=80=99Oliveiro wrote:
> On Sat, 21 Feb 2026 20:10:13 +0100, Bj=C3=B6rn Persson wrote:
>=20
> > In the Ada spirit of preventing preventable mistakes, you can
> > prevent this kind of mistake by writing time offsets as hours from
> > UTC instead of cryptic acronyms. =20
>=20
> UTC is good. Next best is to use timezone names from the tz database.

That's how you configure your computer to display your local time, or
program a world clock to show the current time in various places. The
system clock runs in UTC under the hood, and rules from the timezone
database are used to calculate the local time to display. The timezone
database is well designed for its purpose, but timezone names are not
good for agreeing on a meeting time.

First, it requires people to keep track of how other countries play
with their clocks. How many people in Auckland know offhand whether
Lisbon and Madrid keep the same time, or when the clocks jump in
Asunci=C3=B3n?

Second, it's sometimes ambiguous. 2025-10-26T13:30 in Pacific/Auckland
was 02:30 in Europe/Brussels =E2=80=93 and an hour later, 14:30 in
Pacific/Auckland was also 02:30 in Europe/Brussels.

When a time is given in UTC, each recipient only needs to know their
own offset from UTC, and it's never ambiguous.

> E.g. =E2=80=9CCET=E2=80=9D works (regardless of daylight saving) as a sho=
rter
> alternative to =E2=80=9CEurope/Brussels=E2=80=9D

In the timezone database, that alias makes some sense. If you tell your
operating system that its timezone is "CET", then it's reasonable for
the operating system to assume that it shall swap back and forth between
CET and CEST according to the EU's Dumb Silly Time rules.

In a meeting invitation, specifying the time as "CET" when CEST is in
effect will cause misunderstandings, especially in March/April and
October. A recipient might assume that you mean UTC+01:00 and that there
won't be any Daylight Saving Tomfoolery at that time.

Bj=C3=B6rn Persson