MBS-486: Add support for years BCE

[reosarevok]

Implement MBS-486

We have had kinda semi-broken BCE support for decades, but we have legitimate artists who were born and died BCE, and places old enough that they were founded BCE, for example. This adds proper support for BCE dates.

The dates are stored in standard astronomical format (1 BCE = 0) but they are always shown to the user as the more intuitive version without a year 0 on the website (including for entering and editing). On the API, which is mostly meant for machine usage, the astronomical format is retained.

Year 0 is blocked when editing since it's not a valid year in BCE style. I added a more precise error when validating and in React forms. I did not bother to implement the same error in TT, since the date is rejected as invalid there anyway, which is still correct (just slightly less clear).

[mwiencek]

I didn't test this yet, but just a few small things I noticed so far

[mwiencek]

This seems like a good start.

I can't enter "-0001" in the release or relationship editors, but I'm not sure these are useful there (i.e. if it's worth fixing the validation in two more places). Anyway, those cases will likely start working as we consolidate the date period components in the future.

[reosarevok]

It might be useful in the relationship editor (but quite rarely) and should probably never happen in the release editor anyway. I could add it to the relationship editor, if we want to. We might need to check if it anything needs to be changed in the alias form fields if those get merged sooner.

[reosarevok]

Rebased this on current master, seems to actually work fine in the alias form too, so hopefully it's still fine!

Bringing this back because the few ones we already have are causing issues, see https://community.metabrainz.org/t/bc-dates-issue/551104 :)

[yvanzo]

Wouldn’t that break JSON+LD given https://schema.org/Date?

[reosarevok]

Well, in theory ISO_8601 supports BC years (https://en.wikipedia.org/wiki/ISO_8601 says so at least) and I assume given there's plenty of philosophers and whatnot probably supported by schema.org, they are able to parse those. But I haven't actively tested JSON-LD on these, are you seeing issues, other than the year being negative?

[yvanzo]

Well, in theory ISO_8601 supports BC years (https://en.wikipedia.org/wiki/ISO_8601 says so at least)

Not like that; See Monkey’s comment about it. It requires at least five digits or it can be mistaken with a shortened notation.

(By the way, that comment has been entered during Summit 19; See related notes.)

[reosarevok]

Hmm. I'm not sure I'm seeing the issue. My understanding is that if it goes over the 4 digits (plus - sign) then we need to have a specified number of extra digits, but the example just after for example mentions that 2BC = −0001. The LOC specs for example have 4 digits by default, it seems: http://www.loc.gov/standards/datetime/

[reosarevok]

This now works on relationships, since they use the React components. It doesn't work on the release editor, but given BCE releases are AFAICT not a thing, it's probably fine.

That said, there's currently a bug with relationships - we're meant to enter the year as BCE, but store it as astronomical. As such, since formatDate adapts the date by removing 1 from the year if it's 0 or less, the relationship editor shows not-yet entered dates as one year earlier than it should.

[mwiencek]

If I understand the issue correctly, PartialDateInput stores dates in BCE format in its state. And I guess we can't change that because other pages using it (edit profile form, alias edit form, external link attribute dialog) have to post BCE dates to the server.

Perhaps we can change formatDate to accept an additional argument that specifies what format the input date is in?

[reosarevok]

Yeah. I was just not sure how to tell whether the date is new (state-only) or old - how would you keep track in a sane way?