aboutsummaryrefslogtreecommitdiff
path: root/_posts/2023-08-17-25-hour-time.md
blob: 477b6dd3b4b9bb7f6077887f0bb40e7844da3b09 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
---
title: 25-Hour Time (and the Secret Third Half of the Day)
---

you know how if you're up past midnight, on some level it's still the same day until you go to bed, no matter what the calendar says? well, if you've ever wished that there was notation to unambiguously refer to a current date and time when the current date is somewhat vibes-based, you're actually in luck, because this is a solved problem, although depending on your preferred time notation it may require some creative extension.

## It Came from Public Transit

<small>(Opinions, as always, are my own and not that of my employer.)</small>

Some public transit systems run 24-hour service, but many shut down for a bit overnight, which is less convenient for riders but gives staff some time to reset and maybe even take care of some small maintenance tasks without disrupting any scheduled trips. Denver's D line trains, for example, start at 3:48 AM and end at 12:21 AM the next morning (on weekdays, at least). This creates some interesting problems, because if you spell "12:21 AM the next morning" as `12:21 AM`, it looks like it's before `3:48 AM`, but it isn't, so you need to spell that differently.

Conveniently, this problem is solved in the¹ standard for public transit schedule data, [GTFS](https://en.wikipedia.org/wiki/GTFS). It's a machine-facing interchange format, so it uses 24-hour time for parsing simplicity, so it spells "3:48 AM" as `03:48` and "1:30 PM" as `13:30`². The way it handles times the next morning is extremely simple: if "11:59 PM" is `23:59`, then "12:00 AM the next morning" is `24:00`, and "1:13 AM the next morning" is `25:13`, and I'm writing this sentence at "2:14 AM the next morning", or `26:14`. [Apparently](https://en.wikipedia.org/wiki/24-hour_clock#Times_after_24:00), this is occasionally done in countries that use 24-hour time by businesses that run past midnight.

If you say "oh yeah, i wrote that at 2023-08-16 26:20", even if people aren't familiar with beyond-24-hour time, they'll probably figure out what you mean.

## Welcome to Arco AM/PM Mini-Market

Unless they don't grok 24-hour time at all, like me. A trick like that doesn't really work as nicely with 12-hour time - the minute after `11:59` is already `12:00`, and by the time `12:59` rolls over to `1:00` you're an hour deep into the next half of the day anyway. If you want to have times the next morning in 12-hour time, you have to reach a little deeper into the notation.

A system I was dealing with at work has a really nice solution to this. For space efficiency, it spells "11:30 AM" as `1130a` and "9:15 PM" as `915p`, and then the minute after `1159p` is `1200x`, which I suppose would expand out to "12:00 XM" but I prefer with just the `x`. For sheer intuitive clarity, it doesn't match the 25-hour solution — `x` as an abbreviation for "AM the next morning" is not something you'd be likely to just guess — but if you see it in a list of times with some `a`s and then some `p`s and then some `x`s it's not hard to guess that that's what it means. I have no idea if this sort of thing (or some other solution to this problem) is common outside my specific job.

If you say "I wrote this sentence on 2023-08-16 at 229x", people will only have a clue what you mean if they're already familiar with this concept. Most people won't be, but if you're taking notes for yourself, you will be.

## Completely Missing the Point of Everything

But this is Cohost, and we are no strangers to goofy time notation here. I am not, myself, a .beat time enjoyer, but I know it's a feature and I think it's got several users at varying levels of irony. One of the main things I don't like about .beat time is that it also alienates you from the current date, but we're aggressively solving that in other notations, so can we solve it here too?

25-hour time demonstrates that it can make sense to reach past the bounds of the time system to express times past the edge of the calendar date; there is no authority who can stop us from doing the same thing to .beat time. I'm writing this on 2023-08-16 at @1400 (which mere mortals might write 2023-08-17 @400).

Terrifyingly, on account of time zones stretching in both directions, this could allow for someone west of Switzerland to experience **negative .beat time**. By my math (and the math on [SwatchClock.com](http://www.swatchclock.com/convertTime.php)), someone waking up in Sydney, Australia on 2023-08-17 at 8:00 AM local time would conventionally write that as 2023-08-16 @958 but could instead write it as 2023-08-17 @-042.

The entire point of .beat time is to be absolute and global, and the whole point of this endeavor of vibes-based current date is to be anthropocentric and subjective, so this borders on heresy. In addition, it is almost completely useless as a way of communicating anything to anybody - positive overflow is at least trivial mental math to do, but turning a negative .beat time into a normal .beat time would be, at least for me, in that perfect sweet spot where it's too simple to pull up a calculator but not simple enough to be confident that I'd get the right answer doing it mentally. If you have .beat time enjoyer friends, you can probably ruin their day with a negative .beat time, but that's as much use as anyone will get out of this concept.

## Exiting the Target Audience

“But Cactus,” I hear you ask, “isn't this lopsided towards people who stay up inadvisably late? What about people who wake up inadvisably early? Don't they deserve wacky time notation, too?”

Nope!

Well, that's not fair. To be more specific:

1. If you want to do negative time in 25-hour time, what's the minute before midnight? `00:-01`? `-01:59`? Both of those make me sad.
2. Coming up with a secret fourth abbreviation for "PM the night before" is probably not difficult, but there's no canonical right answer there.
3. Negative .beat time could cover this use case anyway, and also very much shouldn't.
4. You're into real sickos territory by the time you're waking up as early as 4am, and that's still four hours away from needing anything like this. By contrast, staying up until like 1230x, which is in the range that benefits from this, is not really that out there.

Unfortunately, it is now 27:05 / 305x / @1420 (nice), and I need to go the fuck to bed.

---

1. or at least *a* standard: as I recall, there are several standards for public transit schedule data, and different ones are popular in different parts of the world; GTFS is big in the US

2. strictly speaking, those would be `03:48:00` and `13:30:00` on account of seconds also existing, but that's not relevant here. also not relevant here is the way GTFS avoids getting pranked by DST transitions; if you're curious and/or bored, look that one up.