-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Include last modified date for a resource #546
Comments
I have to admit I don’t fully understand the diversity of things that we could find in the headers! My gut tells me that we should standardize/convert to YYYYMMDDHHMMSS. But that is not a strongly held conviction. What do you think @ruebot ? |
If we're trying to help researchers, and I'm thinking of folks that have gone through our cohorts, we should format it the same as the
@digitalshawn you were basically looking for this, right? If so, I'm sorry I completely missed I could grab this date from the headers, and this would have really helped out your team. |
…ble. (#547) * Adds `getLastModified` for `SparklingArchiveRecord` * Adds `CovertLastModifiedDate` to convert RFC 1123 dates to `yyyyMMddHHmmss` * See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified * Implement `last_modified_date` column for * `.all()` * `.webpages()` * `.images()` * `.pdfs()` * `.audio()` * `.videos()` * `.spreadsheets()` * `.presentationProgramFiles()` * `.wordProcessorFiles()` * `.css()` * `.html()` * `.js()` * `.json()` * `.plainText()` * `.xml()` * Update tests * Resolves #546
Working on trying to get better date support for a given resource in the last-modified-headers branch. It requires an upstream update to Sparkling.
This is what it looks like now:
The big question before proceeding with implementing this, is do we want to keep the original date format from the headers, or convert it to YYYYMMDDHHMMSS? The only reason I haven't moved forward with it is dealing with the potential locale format changes of the header responses. According the spec, it should always use GMT as the timezone, but I think the days and months could be done in any language. So things could get tricky there. So, should we implement a YYYYMMDDHHMMSS or leave it up to the researcher to modify the date format?
The text was updated successfully, but these errors were encountered: