Jessica Stokes

internet-ti.me

9:30 am, 26 Feb 2022

I built a website to help with organising events using Internet Time; internet-ti.me!

Internet Time is a quirky time standard Swatch launched on some of their digital watches just shy of the turn of the century, in anticipation of our increasingly connected world.

The core idea being that it avoids time zones altogether by centralising on a single, simplified time notation of numbers between @000 and @999, and each person need only understand where their day falls on the cycle to organise events on easily shared terms.

I've been a big fan of it for a while - it’s an April fools easter egg in my shell configuration, I wrote an Apple Watch app to put it on your watch face, and now this!

internet-ti.me's home page is a live Internet Time clock. It shows the current Internet Time, the same for everyone across the world, and a set of local time conversions, including the browser's current local time.

Additionally, you can link to a specific Internet Time - so if for example I am organising an event for @167 in my evening, I can link to https://internet-ti.me/@167, and anyone can click that link to see when it is at a glance in their conventional time zone.

But the secret sauce is in the social metadata - linking to that time on Twitter1, iMessage, Telegram, Discord, Slack, or anywhere else that shows an Open Graph or Twitter Card-powered2 preview, will embed the time zone conversions directly in-context! Here's an example of what it looks like when embedded in something like Discord:

internet-ti.me
@167
is 19:00 PST, 22:00 EST, 03:00 UTC, 04:00 BMT, 12:00 JST, 16:00 NZDT

internet-ti.me card for @167

I've been using Internet Time with these social embeds to organise events with friends for a while now, and this has been handy for sharing with people who are less Internet Time obsessed than I am 😅

Learning about CGI start-up time years late

Initially, I wrote internet-ti.me in Python as a pair of CGI scripts, but eventually I discovered a problem.

The CGI scripts would start and run in under two milliseconds on my M1 MacBook Air, and I simply didn't question it until it ended up running about five hundred times slower on my actual web host3. Every page load therefore incurred about a second of just Python init time.

After some profiling and head scratching, and ultimately consulting with some more Python-inclined friends, it turns out that booting up the Python process incurred some not-insubstantial costs of initialising modules.

Even though my web host are using SSDs, they're not even close to the same class as that in my MacBook Air; the random access throughput of loading all of the Python modules, requiring the finding, reading, parsing, and executing of a not-insubstantial number of files, was seemingly the biggest culprit.

With that in mind, I ported it to Flask, which along with being a persistent process whose startup time is effectively irrelevant to request times, also had the benefit of making it easier to share code between routes, and remove some of the boilerplate.

Consequently, all the dynamic page loads came down from about 1,300ms generation time to a much more palatable 100 to 300ms. Does it matter that much in the grand scheme of things? Not really, but given my web host bills by resource usage I believe most of what I was being accounted per request was literally just that Python init time. Oops!

Further optimisations

In search of even more speed and fewer bytes to send, I wound up changing preview images from 32-bit RGBA PNGs to 8-bit indexed PNGs. This saved about 65% in bytes transferred, and I can barely tell the difference between the old and new social images unless I pixel peep.

My next ultimate goal is to add an interactive converter tool, so you can adjust the Internet Time or any of the conventional times and pick a time for an even without guessing times ☺️

1

The @ is actually optional in the URL, because Twitter’s username autocomplete is kind of sticky once you type an @, even in the middle of a link

2

These are technically sort of competing but ultimately complementary standards; using both nets you broader compatibility, with things like Discord even requiring the use of Twitter Cards metadata to control the format of inline displays

3

I use NearlyFreeSpeech.NET for this, they're good!