New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add additional date parsing and normalization for downstream consumer… #25
Conversation
c80508e
to
ba85413
Compare
a11ce1d
to
9f32117
Compare
83a0919
to
c723cfc
Compare
1 similar comment
1 similar comment
Mods::Date::MarcFormat.new(xml) | ||
when 'edtf' | ||
Mods::Date::EdtfFormat.new(xml) | ||
# when 'temper' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not supported? Should this be removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stanford doesn't have any examples of this, but it's called out as one of the supported MODS formats. I figured a comment was the best way to leave a clue about where one might add support if they cared. 🤷♂️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work. My only comment is that the cleanup
functions are using the same/similar regular expressions as your big case statement for routing to the appropriate Date class. So those might be shared with a comment containing an example of that format.
@drh-stanford: how about 278ea0b? |
Yes, I find that more readable. Thanks |
1 similar comment
…s to extract actionable information from a variety of date encodings
278ea0b
to
cb779b1
Compare
With @drh-stanford 's comment being addressed.. 👍 |
…s to extract actionable information from a variety of date encodings.