Reimplement date field validator as validation rule #138
Conversation
| expect(iD.utilNormalizeDateString('-4003').value).to.eql('-4003'); // beyond displayable year range but still valid | ||
| expect(iD.utilNormalizeDateString('31337').value).to.eql('31337'); | ||
| expect(iD.utilNormalizeDateString('-31337').value).to.eql('-31337'); |
There was a problem hiding this comment.
These years are well beyond the minimum year of 3999 BCE set in OpenHistoricalMap/issues#28 and the maximum year equivalent to the current year at any given time. However, these year thresholds are only for display and filtering purposes. A truly primordial natural feature shouldn’t prevent the user from saving, nor should a building slated for demolition in a year’s time. If we want these to be hard limits, then the API should enforce them and expose them via the capabilities API method.
| }); | ||
| it('rejects malformed dates', function() { | ||
| expect(iD.utilNormalizeDateString('1970-01--1')).to.eql(null); | ||
| expect(iD.utilNormalizeDateString('197X')).to.eql(null); // no EDTF for now |
There was a problem hiding this comment.
Validating the start_date:edtf and end_date:edtf keys should wait until we have dedicated fields for these keys. Parsing EDTF is somewhat more complex than parsing ordinary ISO 8601, since we can’t lean on the browser to bear the brunt of parsing them.
| // Fall back on whatever the browser can parse into a date. | ||
| date = new Date(raw); |
There was a problem hiding this comment.
This fallback is what allows for some natural language syntax to be parsed successfully. The specific supported natural language formats depends on the browser, language settings, etc., so it’s only a best-effort fallback. Anything produced by this code path still results in an error presented to the user, but there’s a suggestion to reformat the tag value to what the Date constructor interprets the value as.
| expect(iD.utilNormalizeDateString('1970-12-32').value).to.eql('1971-01-01'); | ||
| expect(iD.utilNormalizeDateString('1970-02-29').value).to.eql('1970-03-01'); | ||
| expect(iD.utilNormalizeDateString('1970-00').value).to.eql('1969-12'); | ||
| expect(iD.utilNormalizeDateString('1970-23').value).to.eql('1971-11'); // no EDTF for now |
There was a problem hiding this comment.
I’ve already made the mistake of entering EDTF year-season combinations into start_date and end_date a few times. It’ll be nice to get warned about this mistake instead of having to notice that the time slider never filters the feature out.
1ec5
force-pushed
the
ohm-date-validator-445
branch
from
7d7f7da
to
14bdb35
Compare
Added a date format validator to the invalid format validation rule.
1ec5
force-pushed
the
ohm-date-validator-445
branch
from
14bdb35
to
3929208
Compare
|
I rebased the most substantial part of this PR onto the latest staging branch for OpenHistoricalMap/issues#395. I omitted the commits that rolled back #81, which have been completely superseded by this PR. |
|
@1ec5 this looks fantastic, thank you so much! @danrademacher am a bit confused with the branches :( - but do you guys have everything you need to integrate? Let us know if we can help! |
|
Just tested this locally -- the screenshots should have alerted me to how awesome this is, but using it live re-inforced -- it is very cool! |
|
@danrademacher is this now live on https://www.openhistoricalmap.org/? |
|
Unfortunately, no. We have been having a bunch of problems with our local development setup after catching up with upstream OSM and iD, and iD is currently failing on our staging site -- but for reasons that we're still trying to figure out... Documented in OpenHistoricalMap/ohm-deploy#189 (.local dev issues) and at OpenHistoricalMap/issues#476 (iD failing on staging). We escalated this to get more help from our friends at DevSeed and I hope tomorrow we will have progress on local dev that will allow us to fix new iD inside rails and get this out to the community! |
Replaced the date format validator from #81 with a user-friendlier check within the existing invalid format validation rule. The new rule comes with a one-click option to reformat a malformed but understandable date, wrapping around months and years as necessary, as well as an option to remove the malformed date.
Fixes OpenHistoricalMap/issues#445.