How should language aliases be used with datetime2?

Question

Consider the following code:

\documentclass[british]{article}
\usepackage{babel}
\usepackage[utf8]{inputenc}
\usepackage{datetime2}
\DTMsetup{useregional}
\DTMlangsetup[en-GB]{ord=raise}

\begin{document}
  \today
\end{document}

As expected, this produces:

Perhaps somewhat naïvely, I would expect the following code to produce the same results:

\documentclass[british]{article}
\usepackage{babel}
\usepackage[utf8]{inputenc}
\usepackage{datetime2}
\DTMsetup{useregional}
\DTMlangsetup[british]{ord=raise}

\begin{document}
  \today
\end{document}

but it does not:

The documentation for datetime2 does suggest that language aliases may not be entirely equal. What I don't understand is how to distinguish them conceptually. What principled distinction does the package draw between british and en-GB for example, which would make sense of the apparent discrepancies?

Answer 1

Short Answer:

If you want to adjust the style of a particular datetime2 module, you need to use the name of that module. So for the en-GB module (defined by datetime2-en-GB.ldf) you need to use en-GB as the identifier. Note that you can also just do:

\documentclass{article}

\usepackage[british]{babel}
\usepackage[useregional,warn=false]{datetime2}

\DTMlangsetup{ord=raise}

\begin{document}

\today

\end{document}

The language alias is picked up by tracklang which is internally used by datetime2 to determine the required language/region module, so it's a babel alias rather than a datetime2 alias.

Long Answer:

As much as I like LaTeX, the international support is messy. This is, presumably, due to its age and the general lack of consistent localisation support in computers when it was first developed¹ (and even more so when TeX was developed). This has resulted in fragmented and incompatible internationalisation branches. So there is babel with its own set of aliases (such as british and UKenglish), polyglossia with a different interface and some different aliases (such as variant=british or variant=uk), translator with another set of aliases (BritishEnglish), and then there are packages for a specific language, such as ngerman. There are other language-related packages that I've heard of, but never used, and I suspect there are also some that I have not only never used but also never heard of.

In additional to all this, there are classes and packages that provide their own language support with different syntax. For example, the isodoc class has the syntax language=en-GB (or language=enGB).

This results in a nightmare for package developers who want to add international support without forcing the user into using a specific language package (such as babel). It ends up with a complicated mass of \@ifpackageloaded{polyglossia} ... \@ifpackageloaded{babel} ... \@ifpackageloaded{translator} ... (which ones have I missed!)

The easy solution is to tell the user to supply the required language variant for each package that provides localisation:

\documentclass{article}

\usepackage[UKenglish]{babel}
\usepackage[british]{some-package}
\usepackage[language=en-GB]{some-other-package}

Or:

\documentclass{article}

\usepackage{polyglossia}
\setdefaultlanguage[variant=uk]{english}
\usepackage[british]{some-package}
\usepackage[language=en-GB]{some-other-package}

This puts LaTeX well behind modern alternatives. The document language(s) and region(s) would be much better set globally so that all packages that provide regional support don't have to jump through hoops trying to work out this information or demand that the user repeats the information.

It was for this reason that I wrote tracklang to help package developers track down the language and regional options requested by the user without having to burden their code with a load of nested conditionals. Unfortunately it's limited by the fact that some language packages don't provide a convenient way for tracklang to pick up the regional variant provided by the user.

For example, with polyglossia there is a conditional \if@british@locale which is set to true by variant=uk and variant=british and is false otherwise. If this conditional is true, it doesn't tell me whether the user used uk or british. If the conditional is false, it doesn't tell me if the user used australian, newzealand, us, etc.

So british / UKenglish are babel aliases, british / uk are polyglossia aliases, BritishEnglish is a translator setting, etc. So although I could provide a mapping from british to en-GB or a mapping from UKenglish to en-GB, I would also need to add aliases for every other possible language package, otherwise users would be puzzled as to why some aliases work but others don't, and this really isn't feasible as I'd have to constantly monitor all language package development.

There is a further complication for datetime2, which is that the regional variants provided by babel, polyglossia etc aren't always sufficiently specific.

Suppose I'm in England writing a document in English and I want to display the time including the time zone. (For simplicity the example below just uses \DTMdisplayzone but in real documents this is more likely to occur with commands like \DTMnow.)

\documentclass{article}

\usepackage[british]{babel}
\usepackage[useregional]{datetime2}

\begin{document}

UTC+0: \DTMdisplayzone{00}{00}.
UTC+1: \DTMdisplayzone{01}{00}.

\end{document}

This produces:

UTC+0: GMT. UTC+1: BST.

However, suppose instead I'm in the Republic of Ireland and I'm writing a document in English. The time zone mapping for UTC+1 is now incorrect as it should be IST (Irish Summer Time) not BST (British Summer Time), so in this case, aside from political sensitivities, british is an appropriate option, and it really needs to be:

\documentclass{article}

\usepackage[english]{babel}
\usepackage[en-IE]{datetime2}

\begin{document}

UTC+0: \DTMdisplayzone{00}{00}.
UTC+1: \DTMdisplayzone{01}{00}.

\end{document}

This now produces:

UTC+0: GMT. UTC+1: IST.

The file datetime2-en-GB.ldf is no longer loaded, but instead datetime2-en-IE.ldf is loaded and the style setting used in the optional argument of \DTMlangsetup should now be en-IE.

Similarly, if I was in, say, Malta, I'd need to use en-MT to get the UTC+1 time zone displayed as CET.²

So the british alias can be ambiguous, and I think it's better practice to know the actual name of the regional module or just omit the optional argument to \DTMlangsetup, as this makes the code more portable in the event that it's reused in a document that uses a different alias.

---

¹If I recall correctly, LaTeX2.09 didn't even have commands like \contentsname. They're certainly not listed in the index of the 2.09 user manual from 1986.

²Not all the datetime2 language modules have regional variants with ISO codes as there's a limit to my world knowledge, but I'm hoping that maintainers of those modules will fill in the blanks caused by my ignorance.