Wikifunctions:Type proposals/Gregorian calendar month

Done: Gregorian calendar month (Z16098)

Summary

An enumeration type and the twelve months of the Gregorian and Julian calendars.

Uses

Why should this exist?

To represent the twelve months of two widely used calendars, which will be used to build a type for dates. Dates are useful for many functions, such as those calculating how old a person is, how much time has passed between certain events.

There are already functions that would benefit from this type (and probably should be updated once the type is available):

What kinds of functions would be created using this?

How many days are in a given month in a (non-)leap year?
Translate months to numbers and back
Following and previous months (also, more than just the immediately following or previous)

What standard concepts, if any, does this align with?

the Gregorian calendar
ISO 8601

Structure

Like all enumeration types, the Gregorian calendar month consists of a single key. The key is an identity key.

Values

There are twelve values.

January
February
March
April
May
June
July
August
September
October
November
December

Example values

Value

{ "type": "Gregorian calendar month", "value": "November" }	{ "Z1K1": "Znnnnn", "ZnnnnnK1": "Zmmmmm" }

Validator

The validator ensures that:

the identity key is a reference to a persistent value of Gregorian calendar month

Identity

Two Gregorian calendar months are the same if their identity points to the same persistent Gregorian calendar month.

Converting to code

Note that even though in both cases we translate the months to numbers, the numbers in Python start at 1 and in JavaScript at 0.

Python

Since Python 3.12, calendar.Month is an enumeration with the values calendar.JANUARY to calendar.DECEMBER, which are aliases for the numbers 1 to 12. If possible, we use these constants. If not, we use the numbers 1 (for January) to 12 (for December).

JavaScript

As per JavaScript's Date.getMonth function, the twelve months are represented by a number from 0 to 11.

Renderer

As for all enumerations, the renderer displays a label as a link to the value object.

Parsers

As with all enumerations, there is no parser, but a selector based on pre-defined values.

Alternatives

Instead of an enumeration with all twelve months, we could represent months as numbers (either 0-based as in JavaScript, or 1-based as in Python).
Should Julian and Gregorian calendars have separate types for calendar months?
Instead of an enumeration we could have strings e.g. with the first three letters of the English names (JAN, FEB, ... DEC)
have data such as the order or how many days the months has be defined on keys instead of having functions to provide them

Comments

Support as proposer. — DVrandecic (WMF) (talk) 22:46, 9 May 2024 (UTC)[reply]
Support — 99of9 (talk) 00:19, 10 May 2024 (UTC)[reply]
Support — DMartin (WMF) (talk) 18:00, 10 May 2024 (UTC)[reply]
Support — Dolphyb (talk) 22:24, 10 May 2024 (UTC)[reply]
Would you need a different enumeration for Igbo month name from month number (Z16000), because it has 13 months? GrounderUK (talk) 08:27, 11 May 2024 (UTC)[reply]
@GrounderUK: You are correct, I didn't realize that the Igbo months were different. My mistake. I removed it from the list of functions to be updated above once we have Gregorian calendar months. This would require a different enumeration. It would be great to have a proposal for those too. --DVrandecic (WMF) (talk) 18:50, 13 May 2024 (UTC)[reply]
Question: is there a distinction to be made here between the names of the months and the months as units within a wider date system? For example, ISO date format (which is now largely how the Gregorian calendar is stored and expressed in information systems) could be a type, and part of that notation would be month values, but that doesn't help us interpret the syntax or grammar of (say) "A previous eruption had occurred in January of the prior year" from a sourcetext. In any case, Support. — Arlo Barnes (talk) 00:59, 11 May 2024 (UTC)[reply]
ISO 8601 etc specify that the month is represented by a two-character string of Arabic numerals. This is not one of the alternatives mentioned above. As with Natural language (Z60), we should at least consider including the ISO code as an additional key. We should also consider how we link to the corresponding Wikidata item (in the range January (Q108) to December (Q126)). Linking to the appropriate Wikidata lexeme in a particular language would presumably be achieved with reference to that Wikidata item, in due course. GrounderUK (talk) 08:58, 11 May 2024 (UTC)[reply]
@Arlo Barnes, @GrounderUK: as we are working on enumerations, we are circling in on answers to these questions, and we are convinced that enumeration values should have no further keys besides identity. If we want to connect a month with an ISO two-character string, that can be provided by a map or by a function instead of having that on the month object itself.

This has the added benefit that we don't have to decide whether we want to add the "number of days", the "order in the year", or "the ISO two-character string" to the object, turning them almost into Wikidata items. It's just pure identity.

Yes, natural languages don't really follow that rule. We need to figure out whether we want to retroactively clean that up or how to deal with this. We'll work on this. Ideas are welcome. -- DVrandecic (WMF) (talk) 21:29, 13 May 2024 (UTC)[reply]
Ah, good… I’m generally happy with pure identity. That said, I think true identity belongs in Wikidata. If Wikifunctions needs its own version, fair enough. But “how we link to the corresponding Wikidata item” is very much a “how?”, to my mind, not a “whether”. I suggested on phab:T344170#9758774 that we should consider using a Z2-key, but that is just one idea. GrounderUK (talk) 06:22, 14 May 2024 (UTC)[reply]
It may be worth saying that it seems obvious to me that there is already an easy way for the corresponding Wikidata item to link to the Wikifunctions object. Is it clear that these links need to be bi-directional. --99of9 (talk) 01:46, 15 May 2024 (UTC)[reply]
You are right, in theory. But if an enumeration is pure identity, it is not clear that Wikifunctions needs a separate identity at all. Unlike their properties, Wikidata item IDs are highly stable, so January could just be "Q108". If we decide we do need a separate identity, we need to know how to get from that to the “true” identity in Wikidata. How would an API call get the link? How (in due course) would a function get the corresponding lexeme for some language (or any other property)? Even on-site, it would seem to be a better user experience to be able to navigate to Wikidata directly from an evaluation result (equivalent to January (Q108)). GrounderUK (talk) 07:33, 15 May 2024 (UTC)[reply]
critique

Summary: I think the proposal is for a type and exactly twelve objects of that type, which, taken together, represent its enumeration. Its primary purpose is to provide multilingual support for “months”, in accordance with ISO 8601 (etc). Subject to that, it can also be used to provide multilingual support for other calendars that share an equivalent concept, such as the Julian calendar.
Uses: Dates have a range of uses but not all of them require a discrete concept of “months”. You don’t need to enumerate the months to specify a person’s age (in years, months and days) or an interval between two dates. In Abstract Wikipedia, the two principal use cases that come to mind are support for non-numeric dates (which are customary in many cultures) and support for anaphoric temporality, such as “the following April” or “the previous July”.
Structure: does not deal with the Type, only with objects of the new type. A (Gregorian) calendar month may have only one additional key but the new Type being proposed will have several. It is possible to represent enumerations in a number of different ways. Where each member requires multilingual support, the standard (only supported) approach will be a separate object for each one. Accepting that (without reservation), it does not follow that every enumeration requires its own separate Type. On balance, I’m inclined to agree that “month” should have its own type, although I struggle to justify that view.
Validator: I would think it ensures the value for the identity key is a Reference to a Persistent object with the new Type (equality of both Z1K1 and ZnnnnnK1)
Identity: Good… Do we have an identity equality function? I’d be reluctant to extend Boolean equality (Z844) but, conceptually, “identities” are equal if they have the same type and the same identity; we don’t need a separate equality function for each type, do we? (By extension, we don’t need a separate Validator either.)
Converting to code: Are months numbers or strings? It will no doubt be useful to be able to access JavaScript and Python date functions, but how would Python answer the question: How often does the letter i occur in the months of the year (which depends on the language). In any event, being able to have English tokens for integer representations hardly seems consistent with our goals of having a less Anglocentric programming experience, so I think it would be better to stick to integers for the numeric representation. That said, it would probably be sensible to pass the number as a two-digit string, given that its origin is quite likely to be a date with the month in that format.
Renderer: For Booleans, the result is a link to the object, not just its label. This is okay, but easy navigation to other Wikimedia sites should be the norm for every identity (directly or via Wikidata).
Parser: The selector might have the option to select either numerically or lexically. We don’t currently have a mechanism for linking aliases into coherent sets for a “month picker”.
Alternatives:

We should (also) support internationalized months “01” to “12”
I see no need for a separate enumeration for Julian months (but we should use post-Augustinian Latin labels)
Three-letter abbreviations should be reserved for an English context (e.g. a “month picker”); there should be no uppercase presumption.
Although I am comfortable with the pure-identity approach, this is predicated on acceptable performance. As mentioned in comments above, I believe that an explicit link to Wikidata is more than just desirable. My mind is open to alternative proposals, but my current position is that every identity must have an explicit link to a corresponding Wikidata item (even if we don’t intend to use it).

Support though its annoying that JS month numbers and Python month numbers are different... --DannyS712 (talk) 15:26, 22 May 2024 (UTC)[reply]
@DannyS712: Thank you for the detailed critique! I revisited it today in order to see how the template or this page could be improved, so that writing more proposals for other months is easier. I have changed the text based on the critique.

A few detailed questions:

Re 1., updated text.

Re 3., do you mean we could have had represented enumerations very differently, instead of having the individual values be objects?

Re 4., updated text.

Re 5., the idea was to list the criteria for identity. It does not specify how it is implemented.

Re 6.: months are months, from the view of Wikifunctions, and neither numbers nor strings. When converting to Python and JavaScript, they are represented idiomatically. In order to answer the question "how many i's are there in the months", we first would need a function that maps the months (or, in case of Python and JavaScript, the numbers) to the appropriate strings.

Re 6.: Passing it as a two-digit string would, in my understanding, not be idiomatic in the given languages, and would not allow the use of the built-in date libraries (without another conversion).

Re 7.: updated text.

Re 8.: it almost works if we add the aliases 01, 02, to 12 to the values. Unfortunately, just entering "7" wouldn't trigger the search, because it requires at least two characters. Maybe that should be a task?

Re 9.: thanks for the answers to my questions! Agree on not separating Julian and Gregorian calendar months.

Regarding a link to Wikidata: on d:Q122, the sitelinks do link to August (Z16108), and accordingly, on the latter page, you can click on "Wikidata item" within the Tools menu. That should fulfill that requirement.

Again, thanks for the detailed comments! --DVrandecic (WMF) (talk) 18:01, 13 June 2024 (UTC)[reply]
You are replying to my comments. I’ll respond later; this is just so DannyS712 knows I have it in hand. GrounderUK (talk) 19:45, 13 June 2024 (UTC)[reply]
Oh, that makes sense - I was really confused what was being responded to. I'll leave this to Grounder to respond to --DannyS712 (talk) 23:19, 13 June 2024 (UTC)[reply]

Thank you for your revisions to the text. I have made a couple of further tweaks.

3 needs breaking down. First, my point was that this is a Type proposal but Structure (implicitly of the Type) deals only with instances, without making this clear.

Second, treating this as a proposal for an enumeration (the Type and twelve objects of that Type), the question the proposal should address is why the enumeration should have the proposed solution rather than any other.

To eliminate the alternative of a simple list of twelve items, or a map, we could cite the requirement for each item to have a label in a growing number of languages. So each item must be a Persistent object (given current capabilities).

The rationale for a separate Type for each calendar is more difficult to articulate but one consequence of a single type for month (or sequence of days within a cycle) would be the need to represent the relationship between one month (or sequence) and its neighbours (or, equivalently, to identify within which system it has a given position). In other words, we choose to avoid subtypes.

(As an aside, would we choose to represent chemical elements as a single Type, a single list, a map, a set of (Period) Types, a somewhat two-dimensional array…?)

5 is a subtle hint that we have not actually formalized the representation of identity. I agree that this is slightly off-topic, but I note in passing that identity identity identity (Z16372) actually respects the stated criteria in a way that JavaScript and Python implementations cannot (in the case where there is Type conversion).

6 Yes. At the time of writing, I hadn’t figured out how a function would get access to the labels

Tracked in Phabricator:
Task T366459

The two-digit string representation deserves some attention in the document, given that it is part of the ISO 8601 standard. Please see also the comment from Arlo Barnes. The conversions in code are trivial either way and it’s hard to say which will be more common. The ability to convert a string in some language into some numeric representation (within a date or otherwise) is the more important challenge.

8 Personally, I’m fine with “07” and/or “jul”. I’ll leave the design for a month-picker to the multilingual community, as a sub-task of date-picker.

9 On the explicit link to Wikidata, please see my reply to 99of9. We can, of course, provide the link by means of a community function but I would prefer an explicit key, ideally on the Z2. I see this as the Wikifunctions equivalent of inline citations: it’s not the only way or the best possible solution, but it’s the right thing to do until we agree on something better. GrounderUK (talk) 01:17, 14 June 2024 (UTC)[reply]