.Beat Swatch Internet Time
beats.wiki
beats.wiki
Timezones are failing at all of their jobs. Getting time to correspond to sun position? It can be 7pm here and 7pm there but here it will be fully dark and there it will be still mid-evening. Knowing working hours of shops and government? Everything is all over the place. Everything is fluid and changes with seasons.
Plus, there is this unfair specialness that some countries are at UTC and others have offsets. With global time, everybody gets @0, just for different places it will be at a different sun position. (As long as we find a political way to pick something neutral, instead of saying "that's when the sun is highest in London".)
Finally, we don't have per-latitude calendar and things are working fine for us. It's February here and February in Argentina, and yet life doesn't stop even though it corresponds to winter here but to summer there.
The GMT offset is zero, but it's important to note the difference especially when configuring servers to avoid nasty daylight savings surprises kicking in at at end of March.
There has been talk of moving to a +1 offset all year round for lighter evenings in winter, albeit at the cost of some very dark morning, but given we couldn't even manage Metrication without people still complaining 20 years later, I can't see it ever happening.
The counterpoint is that without the metric system how could we make snarky comments on US-based woodworking videos?
The law requiring metric didn't actually come into force until 2000, these cases were early 2000s. Note that the law to this day still allows for imperial measurements to also be displayed, but they wanted to display in solely imperial.
https://en.wikipedia.org/wiki/Metric_Martyrs
The situation another 20 years later is rosier, even the boomers have spent most their adulthood with metric, and they're dying off now.
Why not just offset the office and opening etc hours by +1?
You can't will a culture of closing up at 4pm during GMT and 5pm during BST. That's just even more confusing.
Also a lot of places and services have different hours during different seasons.
Asking an entire culture to change from 09:00-17:30 to 08:00-16:30 seems awkward and doomed to failure in comparison to simply landing on BST instead.
Sure, if you talk to someone there for the first time, you would need to learn what time is generally day/night. However, you will know that 2-3 times in. Just like you would automatically know that now it's summer in Oz, or 3 hour short days near Arctic circle, if you talk to anyone from there even very occasionally.
Case in point, we have global calendar with no problems.
If you really need to coordinate something across many timezones, you currently have the option to use UTC to specify the time.
Following the sun also gives a lot of context. (i.e. if my flight to China lands at 9p local time, I immediately know that it's going to be night, but if my flight lands at 1PM UTC, I really have no context as to what time of day I'll be landing)
It's at least to make time management in systems much less error-prone and complex, among other things.
> if my flight to China lands at 9p local time, I immediately know that it's going to be night
What does that imply? If you mean "it's going to be dark", not really (you need to have more context to assume it's going to be dark at 9pm, there are places where in summer it's still very much light at 10pm). If you mean something like "buses are going to be running and McDonalds will be open", not really (you'll need to check the schedules anyway).
I'm sure people deal w/ more complex issues, but 90% of it is covered by storing everything as UTC and doing the conversion on the frontend.
> What does that imply? If you mean "it's going to be dark", not really (you need to have more context to assume it's going to be dark at 9pm, there are places where in summer it's still very much light at 10pm). If you mean "buses are going to be running and McDonalds will be open", not really (you'll need to check the schedules anyway).
It implies a lot, including that less things are likely to be open, it's likely to be dark, and that I'll probably want to get to bed within a couple of hours to wake up for whatever I'm doing the next day at a reasonable time in the morning (i.e. how to adjust to the daylight cycle there).
You're so used to it you don't even question that, and if you add to that "@x is when sunset usually happens"... somehow I think the world will not come crashing down.
The total cost/effort of timestamp translation in systems is not as high as people make it out to be.
Not knowing what time it is for my Australian colleagues at all without checking my phone every single time is worse. Remembering N timezone offsets (remember DST and half-hour offsets, too) is worse. Doing UTC translation or adding "my time/your time" every time is worse.
If you talk mental overhead, current system is like 10x of that than global time.
We agreed to meet at "8pm their time" but unless I literally put it into my TZ-enabled calendar app every time the chance I mentally translate it to my TZ wrong is unacceptably high. With global time, meeting would be @123 and that's it. I can keep it in my head or write it down on paper, no confusion and full precision every time. I don't even need to know if it's day or night if it's a remote call with the other side of the Earth, maybe me or my colleague works late, who cares, but I know what time it is there at any moment.
> is not as high as people make it out to be.
It's not just timestamp translation and all the errors that come from that, it's all the rest of it, waste standardizing timezones and moving them around, having to convert time all the time, missed meetings, etc.
I constantly forget which way the half hour difference is between Adelaide and Melbourne / Sydney!
Then I have regular contact with offices in London and LA. For some of the year it’s not too bad, and then our clocks switch the opposite way and it gets less convenient! Which way is which I can never remember.
Queensland doesn’t bother changing their clocks at all.
Writing software that deals with Timezones isn’t too bad these days, but supporting it is as it constantly confuses users I find!
I read the PHP docs and wondered "What in the heck is that?" before Googling it.
Maybe when the nuclear winter makes it dark all the time, or forces us all to live underground, then we can abolish timezones.
On second thoughts, the extra information is probably less complicated, Steve can say "I'm available between @300 and @1000" (maybe he keeps odd hours), and this knowledge plus a glance at the current time can tell me whether I can call Steve.
Steve could also just tell his availability in UTC, and the same lack of maths is needed. Although, we still need maths because most of us don't use UTC time, in the UK only half a year as well. Except Icelanders...
Good luck convincing Aussies, Kiwis and Americans to share their times in UTC without having to ask or doing the conversion yourself.
Hover the timestamp here on HN and you'll see it at least once in your life time :) I'm guessing it's mostly developers, especially ones working internationally, who come across it every day. Others seem to prefer to convert between people's timezone, while we just send UTC+00:00 to each other.
It's actually a problem in these parts that it's not obvious to us whether a time is in UTC or local time. I've found so many things displayed in UTC that people have assumed is local time then summer comes around and everything is off by an hour.
The API shows a unambiguous timestamp, which is the exact same value I see for your comment: https://hn.algolia.com/api/v1/items/46958592
> created_at: "2026-02-10T12:03:56.000Z"
Thank you for helping me discover the source of this little brainwurm.
This was also marketing driven, it seems.
Kinda telling, that they had timezone troubles, even when using Beat :)
"The BEAT system that shows up on the game screen isn't just based on the Dreamcast settings -- it's sent over from the server. And because there are so many different servers in different time zones, it was a bit of a pain to get all of that unified."
https://web.archive.org/web/20021208112249/http://www.sega.c...
And it was always portrayed as a solution for arranging meetings for you and your friends or business people on the other side of planet.
I think the other idea from these times was abolishing phone numbers and using unified global email-like identifiers. And in a way we got this on social media - some people use same account names everywhere - not mention keybase, and we also have instant messengers on smartphones in our pockets.
The fact that it's now on the front page of Hacker News makes me so happy.
The main one, which became my pet peeve about event and meeting announcements, was that they always, always used Standard Time abbreviations, whether it was DST or not DST, they always specified standard time.
So if a meeting was at 3pm on June 13 in Delaware, it was announced as "3pm EST". If the meeting was at 9am on August 8 in California, it was announced "9am PST".
This drove me up the wall because, living in Arizona, there is a legitimate difference for us between "MDT" and "MST". Now if we anticipate this quirk, it is really not a problem, except for edge-cases.
But I complained and asked why they were doing it, and they said they'd always done it that way, and even implied that it was written into policy somehow, and I came to discover it was far more widespread than just our one company's internal comms, and my brain exploded with ASD dissonance.
https://www.swatch.com/en-ch/internet-time.html https://beats.wiki/0
Not sure if it's a bug, but for the date+time permalink at the bottom, the displayed link changes but the underlying href is locked to 7 months ago
From the official Swatch page:
> The BMT Meridian was inaugurated on October 23rd, 1998, in the presence of Nicholas Negroponte, founder and director of the media laboratory at the Massachusetts Institute of Technology.
That’s an oddly-phrased sentence. I wonder what “in the presence of” looks like.
That is what an artificial intelligence would say, unable to comprehend the existence of the physical world :-)
(I've also just finished reading the novel Shroud by Adrian Tchaikovsky, which revolves around a similar plot point, but it's aliens)
It's like saying the Amiga 1000 was launched in the presence of Debbie Harry and Andy Warhol.
Maybe because I'm European and there are direct translations in my native tongue, "in the presence of" sounds just fine if a bit official.
Thanks!
I am unsure whether Swatch still markets watches with digital displays.
Let’s play Fizzbin, everyone!
Decimal time: you divide the day into powers of tens, a 'deci' is 2.4 hours, a 'centi' is 14.4 ~= 15 minutes, a 'mili' is 1.44 minutes ~= 86 seconds and so on.
Great system with convenient lengths, and easy to add duration + date, and convert between different units.
https://en.wikipedia.org/wiki/Decimal_time
Not to be confused with Metric Time:
https://en.wikipedia.org/wiki/Metric_time
Timekeeping units of measurement:
Edit: Swatch internet time
There is "Swatch Internet Time" which is UTC+1. (Wiki never refers that time as Internet Time, good that they couldn't take the term for their time.)
It seems "Internet time" is still free for someone to take, if they can.
Of course it is not insurmountable problem, but for lot of other units milli- tends to represent the lower end of "human scale"; millimeters, milligrams, milliliters, milliwatts, etc are as small as most people will ever use in day-to-day life.
In some ways it would be more convenient if the base unit would be e.g. 1e-4 days (or some other power of 10) so day would be 10 kilos. Understandably it would be lot less elegant but more practical. Deci- would be .86 seconds which is kinda nice.
> There are no confusing time zones ordaylight savings time shifts to worry about.
Also this website (and in the very next sentence - emphasis mine):
> There are exactly 1,000 .Beats in a day, making each .Beat precisely 1 minute and 26.4 seconds long.
Having a laugh.
I'm assuming this cannot be serious, otherwise get thee hence!