Item — HN Reader

emotion note: JNRowe heavily suspires

I was going to say that cal on Linux correctly displays the weird year, then I ran "cal 9 1752" and thought I had misremembered.

Five minutes in to the rabbit hole says Debian uses bsdmainutils for cal, where on other distros you may receive util-linux's version¹. So, it is entirely dependent on an obscure choice of a maintainer whether you get the "missing" days in your output or not.

Made a thousand times stranger if, like me, you have ncal aliased to cal so that it uses your locale's week format. ncal does display the weird September for me, unless called with the -b flag for classic output. The problem is you want the -b flag if you are naïvely trying to fix the Monday should be the start of the week issue with cal.

This is my favourite quirky behaviour of at least this week, if not longer. Tonnes of sensible decisions that all interact in utterly weird ways to make very little sense without The Ultimate Shovel to dig around with.

Interestingly, ncal supports showing you where the changeover happened in various locations by providing the -p flag which shows some more data to expand on peapicker's comment.

You can even play around with the calendars in various locales with ncal by specifying the -s flag, for example "ncal -s GR 3 1924" to see peapicker's Greece example.

¹ https://github.com/karelzak/util-linux/blob/master/misc-util... - Gory handling details

1 comments

> So, it is entirely dependent on an obscure choice of a maintainer whether you get the "missing" days in your output or not.

I think defaulting to removing the days in 1752 is rather Anglo-centric. That was when the British Empire adopted the Gregorian calendar, but other places adopted it earlier or later.

I can think of some other options which in my mind are all superior to using 1752 as a default:

- Work out the appropriate cutoff point based on the user's configured locale or current geographic location

- Use the original introduction of the Gregorian calendar in 1582 as the default cutoff. (This is also the correct answer for Spain, Portugal, France, Poland, Italy, and for the former members of the Spanish and Portuguese colonial empires.)

- Don't use a cutoff and just use the proleptic Gregorian calendar

- For potentially ambiguous dates – basically anything from the initial introduction of the Gregorian calendar in 1582, through to its adoption by Greece in 1923 [0] – ask the user to either choose between Julian or Gregorian, or specify a locale/country/territory for the date (from which the choice can be inferred)

[0] Turkey and Saudi Arabia adopted the Gregorian calendar after Greece did, but they don't count because they never used the Julian calendar – they switched their official calendars from Islamic to Gregorian, in 1926 and 2016 respectively. Greece was the last country to make the Julian to Gregorian switch for civil purposes

> I think defaulting to removing the days in 1752 is rather Anglo-centric.

The utility does use the locale. Since most people here probably have their locale set to en-US (or maybe en-GB/en-CA/etc.), they get the English conversion date. If you were to switch the locale to fr or es, you'd get the 1582 cutoff date. If you were to switch it to sv, you'd get Sweden's conversion date.

> The utility does use the locale.

Which utility are we talking about? As the JNRowe's comment notes, there are at least three different versions of cal in circulation: util-linux cal, bsdmainutils cal, and ncal. They don't all do the same thing.

util-linux's cal only supports three modes of operation–proleptic Gregorian, Julian, and calendar reform hardcoded to September 1752; it doesn't support any other reformation date. It uses the locale to decide whether to start the week on Monday or Sunday, but not to decide the Julian-Gregorian transition year.

BSD cal (used on macOS, Ubuntu, *BSD) only supports 1752 as a transition year and ignores the locale. BSD ncal (available on same platforms) supports other transition years and will use the configured locale to decide which one to use; however, it still falls back to 1752 as a default if locale information is not available.

To some extent that was kind of my point. Many well meaning people have tried to make better decisions at various points, but it just increases the amount of unexpected behaviour.

I suspect another better decision wouldn't really help ;)

For such niche behaviour I think I probably fall on the side of bsdmainutils' "cal -b" output. Be byte for byte compatible with old behaviour, and expect people to use something else when they need more accuracy.

Some of the behaviour you advocate for can be implemented using gcal¹, it allows you to use various dates and also specify a manual reformation date with the `--gregorian-reform=<date>` option. It doesn't offer the fuzzy sliding option though, but the manual behaviour is probably good for the people who care about this minutia.

¹ http://directory.fsf.org/project/gcal/