Make EDTF date input more intuitive for #2976

[sylvieed]

Resolves #2976

The problem

Currently, the "Document Date" field under "Additional Metadata" in work settings is required to be in ETDF format and a validation error pops up if it's not:

1 error prohibited the form from being saved:
Document date must be in EDTF format

This works, but isn't very intuitive because some users (such as Molly of History Revealed, who emailed about this issue) don't know what EDTF format is or don't understand what the validation error means.

The solution

A better way to restrict dates to EDTF format is to use an input mask (to yyyy-mm-dd), this pull adds that.

An issue

Though this works perfectly with dates at one specific day, there are more possible date types. EDTF allows:

• year, month, and day (e.g. 2016-05-10) (what this allows)
• year and month (e.g. 2016-10)
• year (e.g. 2016)
• date and time (e.g. 2001-02-03T09:30:01)
• interval (date range) (e.g. 1906-08/1910-12) (this is what Molly of History Revealed was trying to input)

The input mask doesn't allow any input outside of yyyy-mm-dd, so if we want to include other date types, this solution might not fit.

[benwbrum]

If I understand correctly, the input mask performs validation instead of just suggesting text? And that means we won't be able to accept "1854" by itself as an input value?

[coveralls]

Coverage decreased (-0.03%) to 79.376% when pulling df6c140 on additional-metadata-date-input-mask into f1e590e on fromthepage.com.

[sylvieed]

It doesn't perform validation, but it forces the format, not suggests it. If you try to input "1854", it will show as "1854-mm-dd" and you can't remove the "-mm-dd"

It's possible I implemented the mask wrong & it's not working how it should.

[benwbrum]

Okay, that sounds like we've asked you to implement the wrong thing.

I see that the HTML specifications has some slightly different tools available instead of input mask:
The placeholder attribute works like a suggestion; I think it will disappear when the user types in the location. Let's try switching to that here.

The pattern attribute looks a little trickier, since we'd need to provide a regular expression that expresses essentially all valid EDTF formats. (Such a regex might actually exist already somewhere.) This looks like it may force the input to conform to the pattern the same way that a mask does. If that's the case, we'd need to be very careful to get the regex correct.

Could you switch the mask to a placeholder, see how that works, and then explore pattern a bit? We'd prefer accepting non-EDTF dates over not accepting valid EDTF dates.

[sylvieed]

Here's how it looks with a placeholder:

After you type anything in it, the placeholder goes away

I'll look into a pattern more next.

[sylvieed]

pattern seems to just be a validation that shows up right next to the input box instead of the top of the page where we have it now.

This message error pops up when you press "Save changes" and could be edited to give clues about EDTF format. It could also be used in conjunction with a placeholder.

Personally, I don't like this because having different validations in different places across the site seems confusing/inconsistent. However, it is a more immediate validation and could make more sense to users.

[benwbrum]

Let's just go with the placeholder solution then. Your intuition about different validations seems spot-on.

[sylvieed]

OK, that's what's on this branch right now.

[saracarl]

So the problem with this is that if I type "1943" into the field and save it, it pads out the whole data to "1943-01-01". This is not desirable. EDTF says "1943" is a valid date, so it should accept that.

[sylvieed]

It looks like the problem with the EDTF dates being padded to day precision is the edtf-ruby gem we're using. From their documentation:

Most, notably, EDTF dates come in day, month, or year precision. This is a subtle difference that determines how many other methods work. As you can see, dates have day precision by default:

> Date.new(1966).year_precision! == Date.new(1966)
=> false

You can set a date's precision directly, or else use the dedicated bang! methods:

> d = Date.new(1993)
> d.day_precision?   # -> true
> d.edtf
=> "1993-01-01"
> d.month_precision!
> d.edtf
=> "1993-01"
> d.year_precision!
> d.edtf
=> "1993"
> d.day_precision?    # -> false
> d.year_precision?   # -> true

So, Date.edtf(2022) would return 2022-01-01, which is why we're seeing the document_dates padded.

The good news is that the document_date is stored as a string in the database, and is only converted to EDTF (and padded) when it's accessed through the model. In the work model's document_date method:

fromthepage/app/models/work.rb

Lines 214 to 216 in f679cdd

	def document_date
	Date.edtf(self[:document_date])
	end

self[:document_date]            => "2022"
Date.edtf(self[:document_date]) => "Sat, 01 Jan 2022"

So we still have access to the precision of all of the document_dates previously entered.

[saracarl]

Should we check the string and decide how to display it/which EDTF precision to use based on what it contains?

[sylvieed]

We'll manually check the length of the document_date and assign its precision based on that.

We'll include coverage for:

• decades and centuries
• yyyy-mm-dd
• yyyy-mm
• yyyy

We probably won't include coverage for:

• Years before 1000 (we can address this if it becomes an issue)
• Other EDTF specs like intervals, times, sets

[sylvieed]

Day, month, and year precisions as well as decades & centuries now save!

[benwbrum]

Tests fine. Merging.