Conversion between Gregorian and Julian had been done back when the TimeValue was managed in the front-end.
It would definitely by nice to be able to have some widget/gadget that would show/allow converting a value.

But some observations more specific to this bug:
UI sends a value to the back-end parser. Back-end parser always returns Gregorian value since it does not have the specific time ranges implemented.
The parsed value is posted to the formatter which, of course, returns the date in the Gregorian calendar since that one is specified in the parsed value.
The UI itself does not feature any logic regarding calendar management anymore.

Options:

• Implement "defaults" in the parser which would mean having very specific (kind of "magic") logic in the parser.
• Implement "defaults" logic in the front-end overwriting the Gregorian calendar returned by the back-end parser as long as the Gregorian calendar has not been selected specifically. That would mean to have the "defaults" logic in front-end and back-end (since still needed in back-end formatter).
• Evaluate if having multiple "defaults" is worth having the effort at all.

We basically have two bugs about the same issue (the other one being #70398). This one is high/major, the other one highest/major (the only one with "highest" priority and tagged "frontend"). Can we, at least, figure out how that is going to move on?

Denny: We talked about this. Can you have a look and comment with your thinking on it please?

Here is how the UI should work as long as we support only proleptic Gregorian (G) and proleptic Julian (J) calendars:

• when entering a date before 1581, it should understand that date as J (and display a not too obvious option to switch to G).
• when entering a date between 1581 and 1930, it should understand the date as G per default and allow to easily switch to J instead.
• when entering a date after 1930, it should understand the date as G. Although there is no real use case for it, it allows the user to switch to J, but it shouldn't be too obvious.
• if a user has explicitly chosen a calendar for a value, it should stick until the user changes it explicitly again
• if a user is editing a date, the calendar should stick until the user changes it explicitly

I think bug 70398 is a duplicate. It should be merged here and the priority here should be raised to highest. This is currently doing damage to Wikidata.

Whether the implementation is happening in the backend or frontend, I do not really care.

To make sure: the calendar model only refers to the display (and editing). It always displays (and edits) in the explicitly given calendar model. The backend eventually *always* saves the date in G.

I am happy to discuss this as needed.

I am in for that--it is the same behaviour than it was before, although, back then, the front-end parser applied conversion when changing the calendar (which was sort of strange).
When having additional calendars, the behaviour should most likely be the same: The parser detects which calendars the date may match to. While picking the "most likely" (...), there should be hints to switch directly to one of the other calendars.

However, in my opinion, this mechanism of, basically, guessing the calendar cannot be mapped properly on displaying dates, even more when having in mind that there really should be more than Gregorian and Julian. The basic options would be to either have one "default" (Gregorian) only or have no default at all.
First would result in dates before 1581 entered in Gregorian not explicitely being annotated about the date being Gregorian (since, on the contrary, all Julian dates would feature an annotation, regardless of being before or after 1581).
Latter would result in always displaying the calendar name next to the date (even for Gregorian dates after 1581).
Applying any logic guessing the calendar when displaying a date (which is what is done at the moment) feels like a time bomb issue. Although, for an optimization, we could probably apply using "Gregorian" as default in the time range Gregorian was used, exclusively. Eventually, having no default calendar for dates <= 1581 (always display calendar name), and default to Gregorian for dates > 1581 (display calendar name when not Gregorian). To me, that appears to be the most practical solution and avoids generating confusion about having multiple defaults.

OK, I will not fight for the multiple defaults even though they make total sense to me. But displaying the calendar model always does not hurt.

But the calendar model should default to the right model when a date is entered, as stated above, as just discussed with Henning off-Bugzilla, and allow the user to explicitly switch.

No translation / transformation of the date should be done when switching the calendar model. It merely switches the calendar model, but the nominal value stays the same.

• Bug 70398 has been marked as a duplicate of this bug. ***

(In reply to denny vrandecic from comment #4)

Here is how the UI should work as long as we support only proleptic
Gregorian (G) and proleptic Julian (J) calendars:

• when entering a date before 1581, it should understand that date as J (and

display a not too obvious option to switch to G).

Gregory XIII decreed that 4 October 1582 be followed by 15 October 1582 and this was the earliest the change was observed. If you want the default to be governed only by the year, then Julian should be the default for years less than 1582, rather than 1581 as stated in comment #4. This is probably best, because dates are often given to a precision of one year.

It is best to display "Julian" next to all dates in that calendar, since many users only have a vague notion of when the Gregorian calendar first entered into force. Indeed, most dates I have examined in Wikkidata before 1752 that were stated or implied to be Julian in Wikipedia were incorrectly stuffed verbatim into Wikidata, suggesting many users never heard of the Julian calendar.

Aye. It would be great if all bot requests adding dates before 1920 would be required to demonstrate that they understand the two different calendars, and to explicate how they are handling it. Just reading any dates from the article and Charlesmagne and writing it into Wikidata as proleptic Gregorian because this is the default that happens to the API call is just bad.

At least human edits will get usually nudged to be correct by the workflow implemented here. But bots don't get (and should not get) the same kind of nudge.

Why the Wikidata UI displays the stored proleptic Gregorian date value and not the Julian date when calendar is Julian? Please restore the old function. All dates stored in Gregorian and displayed according to the calendar setting.
The current display is unusable.

Do not know right position. User mentioned that it makes no sense to declare dates as gregorian before calendar reform.

In T72395#1088223, @Conny wrote:

Do not know right position. User mentioned that it makes no sense to declare dates as gregorian before calendar reform.

ISO 8601 uses the (possibly proleptic) Gregorian calendar for all dates. When converting a date from a part of the world that was not under the influence of the Roman Empire, such as Chinese or Mayan, is it really Wikidata's place to determine that it is more appropriate to convert to a Julian date rather than a Gregorian date? I think there are sufficient use cases for Gregorian dates earlier than 15 October 1582 that Wikidata should not disallow them or make them harder to use than Julian dates.

What's the status of this? We have changed the interpretation of the internal model as well as the UI and API quite a bit with regard to the calendar model. Ignoring the fact that the data we currently have in the database is inconsistent, is there still a problem with the UI being confusing?

In T72395#1325530, @daniel wrote:

What's the status of this? We have changed the interpretation of the internal model as well as the UI and API quite a bit with regard to the calendar model. Ignoring the fact that the data we currently have in the database is inconsistent, is there still a problem with the UI being confusing?

I thought the internal model was still under discussion, and nothing had been decided on that. See T99674.

At present the user interface will not accept a date that is valid in the Julian calendar but invalid in the Gregorian calendar, such as 29 February 1700. See T98194. Users who observe this behavior are likely to believe that only the (possibly proleptic) Gregorian calendar is supported and disbelieve all documentation to the contrary; action speak louder than words.