eml
eml copied to clipboard
NCEAS
date time format strings need a system
Author Name: Margaret O'Brien (Margaret O'Brien) Original Redmine Issue: 5617, https://projects.ecoinformatics.org/ecoinfo/issues/5617 Original Date: 2012-06-05 Original Assignee: Matt Jones
EML has a formatString element that takes text strings, and the spec give several examples. Translating dates would be much easier if the system which specified the format was included.
This data: 01May2007
The spec example suggests DDWWWYYYY which is specified by the system [unknown]
Another representation of this date is
<formatString>DDMonYYYY</formatString>
which can be read directly by postgresql. So using something like this: <formatString system="sql">DDMonYYYY</formatString>
would be more informative and make interpretation easier for code like the DML.
example doc using this date format: knb-lter-sbc.61.1
Original Redmine Comment Author Name: gastil gastil (gastil gastil) Original Date: 2012-07-05T15:14:43Z
Hi Matt, Well stated. I would assign higher than normal importance to this one because the temporal dimension of ecological data is so important and this limatation in translating dateTime formatStrings has held back some important features in pasta. - Gastil
Original Redmine Comment Author Name: Matt Jones (Matt Jones) Original Date: 2012-07-05T16:39:20Z
The formatString uses the ISO8601 formatting codes. This is in keeping with EML's recommendation that people use ISO8601 compliant dates whenever possible. Supporting multiple different date formatting coding systems just complicates things for consumers, as they then have to be able to do mn conversions of format strings. As it stands now, we only need 1n conversions, because they would all get mapped to ISO8601 format strings. So, any software that consumes format strings has to translate from ISO8601 strings to their desired format, e.g., postgresql in your example. Moving to a system where EML allowed multiple types of formatting strings would certainly make it harder for application developers to fully support all of the legal values that might be found in a EML document from this modified schema. I think it is better to leave it as is with a single format string approach (ISO8601).
Original Redmine Comment Author Name: Redmine Admin (Redmine Admin) Original Date: 2013-03-27T21:31:06Z
Original Bugzilla ID was 5617
Decision needed on approach moving forward. Do we have consensus one way or another? This is related to the new issue #268 that was opened recently.
Big fan of not introducing format strings / systems / etc into EML and focusing instead on using some profile of 8601 for both Dates and DateTimes.
~~Yeah, that could be enlightening. I'll DM you on Slack.~~ Comment I replied to deleted for some reason.