I know what the writer means, of course. He’s telling us that the SpaceX debris will hit the Moon at several thousand feet per second, 1,000 fps being about the speed of sound we’re used to here on Earth. But the Moon isn’t the Earth, so it’s kind of a weird comparison, don’t you think? It’s not as if the booster is going to create a sonic boom. I’d find this less odd if the story were in a normal newspaper or magazine instead of Scientific American.

Again, I realize that the writer is just giving his readers a point of comparison, but is the speed of sound (on Earth) really something most people have an intuitive feel for? I remember learning as a kid to count off the seconds between a lightning flash and the resulting thunder to get the distance to the lightning strike in thousands of feet, but that doesn’t mean I have a strong sense of the speed of sound. Other than “really fast,” which isn’t all that helpful.

It’s mentioned in the body of the article that the speed of the booster at impact, which will be on August 5, is estimated to be about 5,400 mph. That’s about 100 times the posted speed limit on a two-lane highway, which is something most Americans do have a feel for.

By the way, if you have any interest in the problem of space debris coming back and striking the Earth (where the speed of sound might be relevant), you should follow Sam Lawler on Mastodon. She’s a professor of astronomy at the University of Regina and also has a keen interest in the clogging of near-Earth orbital space by the huge number of satellites launched in recent years. Her Mastodon feed is also a great source of farm animal photos, most recently a crop of baby goats.

Earlier this week, I saw this article in Apple News. It’s from the San Francisco Chronicle and discusses a recent report on the safety of the Golden Gate Bridge. The report is one of several reports spurred by the Francis Scott Key Bridge collapse a couple of years ago.

Image from Wikipedia.

Spoiler: the report finds the Golden Gate Bridge safe—quite unlikely to suffer damage from the impact of a ship. This has to do with the Golden Gate’s two towers:

• The south tower (in the foreground) is surrounded by a reinforced concrete protective structure that a ship would have to strike and destroy before coming in contact with the tower and affecting the bridge’s integrity. We discussed the lack of protective structures around the piers of the Key Bridge.
• The north tower is right up against the Marin County shoreline, where the water is shallow. A large vessel would run aground before striking the tower, scrubbing away most, if not all, of its kinetic energy. A ship that wouldn’t run aground before hitting the tower would be too light to bring it down.

A striking omission from the Chronicle story is a link to the report itself. But that appears to be the fault of Apple News. I can’t read the story on the Chronicle’s website because I’m not a subscriber, but this reprint on Yahoo! News includes the report embedded as a PDF and available to download. So it looks like Apple removed the report itself, which is pretty poor form.

The nice thing about finding the actual report, written by HDR, Inc., is that it confirmed some suspicions I had regarding this paragraph in the Chronicle story:

The resilience of the Golden Gate Bridge partly comes from sheer strength. The south tower, on the San Francisco side, is described in the report as a “robust structural feature like no other” and is surrounded by a reinforced concrete protective shell up to 28 feet thick. It can withstand about 50,000 kips of force, or roughly 25,000 tons. In many cases, engineers found, a ship would crumple and absorb its own impact energy before it could seriously damage the structure.

First, it’s not “sheer strength,” it’s “shear strength.” HDR calculated the strength of the protective structure around the south tower to be at least 50,000 kips when that force is attempting to shear through the reinforced concrete wall. They specifically mention shearing capacity, shearing interfaces, and shearing area when discussing this calculation on pp. 59–60 of the report. While it’s true that engineers tend to be crummy writers, we definitely know the difference between “shear” and “sheer.”

Second, I suspect the writer, Brooke Park, doesn’t know what a kip is. When writing for a general audience¹ most people wouldn’t use the word “kip” without saying it’s short for “kilopound.” Which is to say,

There’s no “roughly” about it.²

Still, this oddball paragraph doesn’t affect the overall story and provides the engineers who read it some amusement. Too bad about Apple’s redaction of a link to the report itself, though. That’s sheer incompetence.

(My first thought was that this would be an update to yesterday’s post, but I soon realized it was going to be too long for that.)

The first method starts with a swipe to the left on the message whose sender you want to block. This brings up three options:

The options are

• Trash, which deletes the message.
• Move…, which lets you file the message in a folder.
• More, which brings up the following set of commands:

You may need to swipe up to see the whole list.

Two of these commands repeat what was in the previous screenshot, but a little redundancy never hurt anyone. What we’re interested in is the Block Contact command at the bottom, which does exactly what we want.¹

This is a pretty efficient way to block the sender if you’re in list view and can tell that that’s what you want to do from just the first couple of lines of the message. The next method, which I didn’t know about before Ron’s email, gives you a chance to see more of the message before deciding to block.

Starting again in list mode, long press on the message whose sender you think you want to block. This will bring up two windows, a larger one with a more complete view of the message and a small one with a list of commands.

If you were unsure whether to block the sender from the list view’s abbreviation, you’ll probably decide after seeing this. Tapping on the small list of commands makes it bigger and reveals the Block Contact command.

Why Block Contact is red in this command list and not in the others is one of the wonderful mysteries of Apple interface design.

These blocking methods (thanks again, Ron!) prove that Apple can make reasonably efficient interfaces when it wants to. Too bad it didn’t put the same effort into the blocking method you have to use from message view.

Yesterday, for example, I was going through my mail on my iPhone and came upon a piece of spam. I put it in the Junk folder with the hope that future emails like it would stay out of my inbox, but I also wanted to do something stronger. I wanted to block all future emails from that sender. I’ve done this with other senders many times before, so I know the steps to take, but I decided this time to document the process because it’s so stupid.

Tapping anywhere in the header turns the various fields blue, suggesting that a further tap on any of them will perform some other action. I’m not sure why these fields aren’t blue to start with, but that’s not my real complaint, so we’ll pass over that.

Since I want to block the sender, the natural thing is to tap on the From field. Indeed, a menu pops up with a set of commands associated with that person/address. You might think that one of them would start a new message (as opposed to a reply), but no, which I find kind of weird. More to the current point, though, is that a command named Block Contact or Block Address is also missing.

I know perfectly well that I can block contacts from my phone, so how do I do it? The Copy and Search commands are clearly wrong, and View Contact Card seems even more wrong, as I have no contact card for this person. Nor do I want one—he’s a spammer. But because I once tapped View Contact Card, possibly by mistake, I now know that that’s the choice to make because this is what appears:

It doesn’t show an existing contact card for the sender; it shows a potential contact card, one that I could add to my Contacts app. But also included in the list of things I can do with this potential contact is block him. Which is what I did.

But this process makes no sense. View Contact Card should not be the path you need to take to block someone you have no intention of turning into one of your contacts. It’s not just an extra step (like tapping the header to turn all the fields blue), it’s a step in the wrong direction. No reasonable person who has not already gone through this process would think that View Contact Card is the command you choose to ensure that you never see an email from this spammer again.

The natural place—the correct place—for a Block Contact or Block Address command is on the popup menu you see when you tap the From field. There’s plenty of room for it. Hiding it behind a command whose primary purpose is something else isn’t a matter of taste, it’s an error.

Apple used to think about things like this and put commands where they made sense. I know that Apple has many more products than it used to, but it also has many many more employees and much much much more money. Simple things like this shouldn’t be falling through the cracks.

My favorite picks were the oddballs, the products that weren’t Macs, iPhones, iPads, iPods, or Apple IIs. In other words: the accessories. I was particularly pleased with Jason’s picks of the LaserWriter, the Apple Disk II, the Apple Watch Sport Band, and the second generation Apple Pencil. I confess I was a little disappointed in Myke’s choice of the first generation Pencil, but he more than made up for it by later choosing the Magic Trackpad.

Those of you who weren’t around in the 80s and 90s may think Jason went overboard in putting the LaserWriter in as his third pick, but you’d be wrong. It was both a great product and incredibly important to Apple. Similar comments apply to the Apple Disk II. I never had one—I never owned an Apple II—but I did have its successor, the Integrated Woz Machine, in all of my early Macs.

My oddball entry would have been the AirPort Express. This is not in the “I can’t believe you didn’t pick” category¹ because it’s an oddball even among oddballs, but for a short period of time for a specific subset of users, it was a great accessory.

If you were a business traveler during those few years in the mid-00s when hotels had wired internet access in their rooms but hadn’t yet outfitted themselves with WiFi, the first generation AirPort Express was one of the best things you could pack. It was about the same size as the wall wart power supply that came with your Apple notebook, and it set up a little WiFi network that gave you the freedom to work (or play) anywhere in your room. Even after hotel WiFi became common, I still packed my AirPort Express because it gave me a faster and more reliable wireless network.

I should also mention that “AirPort” was one of Apple’s best product names. Too bad they don’t have any reason to bring it back.

In this morning’s blog/newsletter,¹ Paul Krugman included a couple of unusual graphs that I want to talk about. It took me a little while—longer than it should have—to figure out what he was doing and why, and I’m still not sure I agree with his plotting choices. Let’s go through them and you can decide for yourselves.

The two graphs of interest are made the same way, so we’ll focus on the first one. He introduces it this way:

The closest parallel I know to the Hormuz crisis is the oil shock that followed the 1973 Yom Kippur War. (The 1979 Iran crisis was more complex, involving a lot of speculative price changes.) World oil supply fell only moderately after 1973, but it had been on a rapidly rising trend until then, so there was a large shortfall relative to that trend. In the chart below I show the natural log of world oil consumption with 1965 as the base year:

And here’s the graph itself:

Krugman usually apologizes in advance for the “wonky” parts of his posts, so I was surprised that he just breezed through the “natural log” and “base year” parts of his explanation. What he’s doing here is taking the oil consumption of a given year, dividing it by the consumption in 1965 (that’s the “base year” part), and then plotting the natural logarithm of that ratio against the year. The ratio for 1965 itself is, of course, one, which is why its log is zero.

Using logarithms to plot exponential growth is common because you end up with a straight line. What isn’t common is plotting the logarithm (natural or common) of the values on a linear scale, as Krugman does here. Plotting software typically (always?) offers you the option of plotting the actual values on a logarithmic scale. The advantage of taking that option is that although the ticks will be unevenly spread, the tick labels will represent those actual values, not their hard-to-interpret logarithms.

The interior of the plot would look the same if Krugman had used a log scale for the vertical axis. We’d still see the straight line showing exponential growth from 1965 through 1973, and then the very slight decay after that. The only difference would be the spacing and labeling of the horizontal grid lines.

So why did Krugman make the plot the way he did? I guess the answer lies in the paragraph after the plot:

The percentage difference between two numbers is approximately the difference in their natural logs times 100. So this chart shows that the world was burning approximately 17.5 percent less oil in 1975 than it would have under the pre-1973 trend — a supply shock not too different from what we will see now if the Strait remains closed.

The first sentence of this paragraph is what took me a while to understand. Then I remembered a Taylor series—actually a specialized Taylor series called a Maclaurin series—that I haven’t seen in quite a while.

Consider exponential growth at a yearly rate of $\alpha$. After t years, the value, relative to starting value, will be

(Note that $\alpha$ is expressed as a decimal value. If the yearly growth is $10\%$, $\alpha =0.10$.)

Taking the natural log of both sides of this equation, and using the properties of logarithms and exponents, gives us

where

(I should mention here that because I’m an engineer instead of a mathematician or programmer, I use $\ln$ for the natural logarithm instead of $\log$. I use $\log$ for common [base 10] logarithms.)

This means that $\ln (1+\alpha )$ is the slope of the exponential growth portion of Krugman’s plot.

This is where the series expansion comes into play. As I nearly forgot, we can express this logarithmic term as

and if $\alpha$ is small, the higher-order terms are very small, and

so the growth rate (as a decimal) will be about equal to the slope of Krugman’s graph. To get the growth rate as a percentage, multiply by 100.

Is $\alpha$ small? Yes. For the eight-year period from 1965 to 1973, we see that the natural log of oil consumption goes up about $0.60$. So the slope of that portion of the graph is

which is pretty small.

The thing is, I’m pretty sure that whole “take the difference of the natural logs and multiply by 100” thing seemed like hand-waving to most of Krugman’s readers. If he’d just used a log scale on the vertical axis, he could’ve said that the lost oil consumption was about $17.5\%$, and it wouldn’t have seemed so magical because we’d all be able to see it in the graph.

Unless his purpose was to entertain people like me. In that case, good job!

There are three items that I open quite often and that Spotlight was slow to find:

• My blog-stuff directory, which is where I keep all the text files, scripts, images, and other components that go into making blog posts. Each post, or set of posts, gets its own subdirectory in blog-stuff.
• My notebook index file, which is where I keep a list of all the entries in my paper notebooks.
• My calendrical directory, which is where I keep the code and support files for my current programming project: a Python module implementing the functions described in Reingold & Dershowitz’s Calendrical Calculations. This folder differs from the items above in that I won’t always need quick access to it, but I will until the project is finished.

The key to making a Keyboard Maestro macro to instantly launch a file or folder is the Open a File, Folder or Application action in the Open category. Here’s where you’ll find it in the Actions panel.

The macros for opening the blog-stuff and calendrical folders in the Finder are one-step macros that look like this:

The path to the blog-stuff folder is

~/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff

The calendrical macro looks the same, except it uses the keyboard shortcut ⌃⌥⇧⌘C and opens

~/Library/Mobile Documents/com~apple~CloudDocs/programming/calendrical

(These keyboard shortcuts have the sort of complicated chording I’d never use if I weren’t running Karabiner Elements to turn Caps Lock into a “Hyper” key that mimics pressing ⌃⌥⇧⌘ simultaneously. If you read Brett Terpstra, you’ll recognize the Hyper key.)

The macro for opening the notebook index file is only slightly more complicated:

The path to the file is

~/Library/Mobile Documents/com~apple~CloudDocs/personal/Notebook index.txt

and the second step puts the cursor at the bottom of the file, which is usually where I want it, as I’m typically opening the index to add a new entry.

Even though I’m back with LaunchBar, and I can use it to get to these files and folders quickly, I’m keeping the macros. They’re not that much faster than ⌘-Space and typing a few characters, but they’re more accurate. There’s no risk of typing “cla” instead of “cal” when I want to open the calendrical folder.

When Nicholas Jitkoff (Alcor) stopped developing Quicksilver in 2007 or so, I switched to LaunchBar, and that’s been my main launcher ever since.¹ I gave Alfred a workout for a few months—inspired, I think, by this episode of Mac Power Users—and I’ve tried Spotlight a few times, but I’ve always returned to LaunchBar.

My most recent trial of Spotlight began in late February and ended yesterday. I’d been hearing about the new and improved Spotlight since the introduction of macOS 26/Tahoe, and this episode of Upgrade inspired me to give it another shot. You may recall that as the episode in which Jason and Myke reviewed the results of Jason’s annual Apple Report Card, and they talked about Spotlight as being one of Tahoe’s significant improvements.

So I turned off LaunchBar and began using Spotlight exclusively. It sucked. I hung on that long only because I kept thinking, “Surely it’s going to improve as it learns my habits.” It didn’t. It was unbearably slow when I started using it, and it was still unbearably slow when I finally decided to pull the plug on it yesterday.

How slow? Finding files and folders—even files and folders that I had been searching for and opening for a few days—typically took several seconds (yes, s…e…v…e…r…a…l seconds). Finding and launching apps with Spotlight was much faster, but even that had a noticeable delay. You may remember that Quicksilver was so-named because it was quick—so are LaunchBar and Alfred. Spotlight, despite being a system feature, is not.

So I’m back to LaunchBar. A new release came out during my Spotlight experiment, which was heartening, as I’ve been worried about LaunchBar’s continued viability as a product. I upgraded and reindexed my system (which took only a few seconds), and it feels like I’m back at my Mac again.

One last thing: If you feel compelled to tell me the Good News about Raycast, please restrain yourself. I know about Raycast, and I know that it seems like just the thing for someone who does as much scripting and automation as I do. And maybe it is. But it seems like a project I don’t want to take on right now. If I change my mind, I’ll let you know.

The first calculation works out the days of the vernal equinox in every year from 1961 through 2026. The key function for this is FindAstroEvent, a fairly new function that returns the date and time of the first occurrence of a given event after the given date. I asked for the first MarchEquinox after January 1 of each year, and I wanted the time to be given in Greenwich Mean Time. Since I only cared about the day of the month, I used the DateList function to convert the DateObject returned by FindAstroEvent into a list of year, month, day, hour, minute, and second and pulled out just the third item of that list.

With equinoxes set to a list of 19s, 20s, and 21s, I used the Tally function to count the occurrences of each day number. As you can see, there were 58 20s in the list of 66 equinoxes, so I included that result in the post to show that March 20 is the most common date of the vernal equinox.

The remaining calculations were done to compare the algorithmic date of Easter with the date that Easter would be if it were determined by the actual date of the first full moon after the vernal equinox. So I used FindAstroEvent again, this time setting the event to FullMoon and the date to the equinox dates calculated earlier. That list of DateObjects was saved to the variable fullMoons.

I needed to compare these dates to the dates of Easter for the years of interest. Oddly, Mathematica doesn’t seem to have a built-in function for calculating Easter, but it does have a ResourceFunction. The function is called EasterSunday, and it calculates the date for the given year.

With the lists of easters and fullMoons in hand, I subtracted the latter from the former. If the difference is more than a week, the algorithmic and astronomical Easters aren’t in agreement. As you can see, there are two instances in which Easter is 31 days after the full moon: first in 1962 (which I didn’t mention in the post) and then again in 2019 (which I did). The final calculation was just a repeat of one of the calculations in equinoxes; I did it again so I wouldn’t have to hunt down the 2019 equinox date.

I’m not sure when I learned of the FindAstroEvent function, but it really came in handy yesterday. I’m pretty sure there are functions in Calendrical Calculations that deal with equinoxes and full moons, but I haven’t gotten that far in the book yet.

In its continuing attempt to teach us how calendars work, Scientific American has an article (Apple News link) up today that goes through Gauss’s algorithm for calculating the date of Easter. The article was written by Manon Bischoff, who also wrote the Friday the 13th article I covered a few weeks ago.

There are a few small mistakes in the article: one computational and two definitional. Let’s take a look at them.

The computational error comes in the calculation of the intermediate value p. The article says

where the topless brackets mean the floor function, the integer less than or equal to what’s inside the brackets. The correct equation is

In both equations, k is

i.e., the first two digits of the year (at least until we get to the year 10,000).

In giving the wrong equation for p, Bischoff is following Gauss himself. In the original presentation of his Easter algorithm, Gauss gave the same simple formula as Bischoff, but he corrected it several years later. Why Bischoff is still using the wrong equation two centuries later is anyone’s guess.

Actually, I can guess. Maybe Bischoff’s using the wrong formula for p because it’s simpler and the error won’t manifest itself until the year 4200 (!). Here’s a quick Python script to see the centuries, starting in the 1600s, for which the simpler formula is wrong:

python:
for k in range(16, 60):
  if k//3 != (13 + 8*k)//25:
    print(f'Century {k*100} gives the wrong value')

The output is

Century 4200 gives the wrong value
Century 4500 gives the wrong value
Century 4800 gives the wrong value
Century 5100 gives the wrong value
Century 5400 gives the wrong value
Century 5700 gives the wrong value

I think we can live with a mistake that won’t rear its head for over 2000 years.

I’m less inclined to overlook the definitional errors in the article’s early paragraphs. This one:

For those who celebrate it, tracking what day the holiday Easter takes place on can be a challenge. According to Christian religious traditions, Easter Sunday falls on the first Sunday following the first full moon after the vernal equinox.

And this one:

[T]he vernal equinox, or start of spring, is fixed as March 21. If a full moon occurs on that exact day, March 22 becomes the earliest possible calendar date for Easter Sunday. According to the lunar calendar, the latest possible date for a full moon after March 21 is April 18. That means Easter Sunday never falls later than April 25.

While it’s true that the idea behind the date of Easter is to be “on the first Sunday following the first full moon after the vernal equinox,” when it comes to determining Easter, both the equinox and the lunar cycle are estimated—they aren’t based on accurate astronomical calculations or observations.

First, let’s look at the vernal equinox.¹ One need only think back a couple of weeks to realize that it isn’t “fixed as March 21.” The most recent equinox was on March 20, as were 58 of the 66 vernal equinoxes I’ve lived through. March 20 is by far the most common date for the true vernal equinox. The Church fathers who set the date of Easter used March 21 as an approximation because it made the calculation simple and resulted in Easters more or less when they thought they should be.

Similarly, they used the Metonic cycle—with some occasional adjustments—to estimate when full moons would occur. There are almost exactly 235 lunar months in 19 years, a fact you can use to calculate a good estimate of when full moons occur.² But this is an average, and because lunar months vary in length, the date of a calculated full moon doesn’t always fall on the date of an actual full moon. (There’s also a slow drift that has to be accounted for.)

So although the date of Easter is guided by astronomical events, it isn’t determined by them. As it happens, this year the vernal equinox was, as we said, on Friday, March 20, and the following full moon was on Wednesday, April 1. So having Easter Sunday on April 5 works out both astronomically and algorithmically. But in 2019, that wasn’t the case. The vernal equinox was on Wednesday, March 20; the following full moon was on Thursday, March 21; but Easter Sunday was celebrated on April 21, not March 24.

To recap, my January complaint was that although I could create a complication that looked like it would start a 30-second timer when tapped, that complication actually required a second tap on a smaller button to start it—a stupid way to implement the feature. As of 26.4, the stupidity has been removed. Now the timer starts immediately when you tap the complication.

If you’d like a quick way to set a specific timer on your watch, press and hold on your watch’s home screen, tap the Edit button, and then swipe (if necessary) to get to the complications screen. Tap the complication you want to change to a Timer, scroll through the list, and choose Timers. At this point, you will be given the option to choose either a generic timer complication—one that just opens the Timers app—or one set to one of the specific times you’ve created in the Timers app.

Choose the one you want and go back to your home screen. Now you have a specific timer complication that works the way it should.

(Aside: I wanted a 30-second timer in January because I was doing physical therapy stretching exercises then that were supposed to be held for 30 seconds. I’m not doing those exercises anymore, so I made a 3-minute timer for tea.)

Thanks to Dan for telling me about this. I had given up on this type of complication and wouldn’t have thought to look for the improvement.

Another improvement in 26.4—one that’s sort of mentioned in the release notes—is that you no longer have to tap the small arrow button to start a workout. You can also tap anywhere in the big area around the exercise icon above the three bottom buttons on the Workouts screen. And you don’t have to wait for the arrow button to slowly animate into view.

I bitched about the previous behavior—prompted by a Greg Pierce complaint—in December. It’s almost as if Apple is listening now.

I’ve been working my way slowly through Reingold and Dershowitz’s Calendrical Calculations. This week I hit Chapter 11 on the Mayan and Aztec calendars and came across a notation for modulo arithmetic that wasn’t familiar to me.¹ I figured I’d write about it here on the off-chance that any of you would find it interesting. Also, to make it stick in my head a little better.

The notation came up in the section on the Haab calendar, a sort of solar calendar that the Mayans used along with the Tzolk’in and Long Count calendars. The Haab calendar has 18 months of 20 days each and then a 19th sort-of-month with just 5 days. There’s no year number in the Haab calendar, so there’s no way to convert directly from the Haab calendar to other calendars. But there is a way to get a date in another calendar that’s on or nearest before a given Haab date.

Reingold and Dershowitz use a “fixed” or “RD” calendar as their way station between all the calendars. It’s a single day number that counts up from what would have been January 1 of the Year 1 in the Gregorian calendar if the Gregorian calendar had existed back then. In this system, 0001-01-01 is Day 1 and today, 2026-03-27, is Day 739,702.

The function that finds the closest given Haab date on or before a given fixed date is called mayan-haab-on-or-before, and it’s defined this way in the text:

What’s odd about the modulo notation in this definition is that the thing after “mod” isn’t a divisor, it’s an interval: the half-open interval between date (inclusive) and date – 365 (exclusive).

Here’s how R&D define this interval modulus, both in Chapter 1 of Calendrical Calculations and in this ACM paper:

As long as the two ends of the interval aren’t identical, the answer will lie in the range $[a..b)$. This notation is helpful in shifted modulo operations like the one in mayan-haab-on-or-before because it explicitly tells you the range of answers you’ll get. The idea is that the resulting fixed date will be anywhere from 0 (inclusive) to 365 (exclusive) days before the given date.

(The normal modulo notation, $n\mathrm{mod}m$, could be written as $n\mathrm{mod}[0..m)$, although this doesn’t seem particularly helpful.)

Note that in mayan-haab-on-or-before, the interval goes backward, which means the divisor in the standard mod function is a negative number: –365. If you’re implementing this function in a programming language, you have to make sure that using a negative divisor in your language’s mod will give you a negative answer. This means that mod must have a floored definition. The mod function in Lisp, which R&D are using, and the % operator in Python, which I’m using as I reimplement R&D, both use the floored definition.

I mentioned earlier that the 19th month of the Haab calendar is an oddball because it has only 5 days. As it happens, today is smack in the middle of that 19th month, which is called Wayeb or Uayeb, depending on whose transliteration you use.

Another odd thing about the Haab calendar—something that computer programmers must love—is that the day numbers within a month start at 0, not 1. So Monday, which is the start of the next Haab cycle, will be 0 Pop, Pop being the name of the first Haab month.