Open 7yl4r opened 3 years ago
@7yl4r I suppose we could do that and I will discuss in the QC task team. We opted for the unix times approach under the assumption that parsing ISO 8601 dates in all its variants (including intervals) is generally harder than converting a unix time. Most languages will support this conversion without the need for additional packages or libraries, the Python standard library has datetime.fromtimestamp()
and base R has as.POSIXct()
for example.
You make a fair point that unix time might actually be more user-friendly than iso8601 but I know at least one person that threw away date_mid
because it doesn't look like a date and they didn't realize it was useful.
Thank you very much @7yl4r ! Based on the discussions today, the project team agrees to have all the eventDate
from OBIS to be in ISO8601.
I know that the DwC standard does not require ISO8601 for
eventDate
but I would like to advocate that OBIS transformeventDate
values into ISO8601 before exposing them over the API or mapper downloads.This would make data consumers' lives much easier. Right now my recommendation for data consumers is to use
date_mid
, a non-DwC field in user-unfriendly unix time.I propose that part of OBIS QA+QC should be parsing the given eventDate and pushing anything non-ISO8601 into the
verbatimEventDate
column. Is there any drawback to that?