Date BCE

m.neiger

Hi,

It seems Zotero chokes on dates BC or BCE, trying to enter "c. 480 BC" or BCE or "480 BCE" disrupted the date field.
It was actually for an Artwork object type, but I would suspect the issue to be generic.

Cheers,
Marc

bdarcus

The problem is Zotero really needs to store dates that computers can understand, and there aren't really any widely understood conventions for these sorts of dates. I agree it's a problem to be solved, but it's not that straightforward.

Dan, if you're reading this, I think there might be a way around this in RDF import/export, and that it is to just assign a datatype that specifies a string is a BC date. E.g.:


<dc:date
rdf:datatype="http://purl.org/ontology/dates/bc">523</dc:date>


That may be a way to tackle other tricky dates.

bdarcus

Just a followup to this after doing a little poking around. It turns out the XSD gYear datatype does support BCE encodings. One does this be prepending a "-" character. So this would be valid:

<dc:date
rdf:datatype="http://www.w3.org/2001/XMLSchema#gYear">-0523</dc:date>


... or in N3:

<http://ex.net.1> dc:date "-0523"^^xsd:gYear .

m.neiger

I don't know how it should behave on the UI side, but entering -480, ended up printed as -480, not 480 BCE. It did not disrupt Zotero but was not very satisfying, although it is for the time being my way to cope with this.

I would says, that if it would just keep the date field 'as entered' in the case of BCE or other unconvertible dates, that would be enough for current zotero functionality.

dstillman

I would says, that if it would just keep the date field 'as entered' in the case of BCE or other unconvertible dates, that would be enough for current zotero functionality.

Yes, it's supposed to do that, while storing a standard date as well for sorting purposes if possible. This is just a date parsing bug (stemming, in fact, from partial—but not complete—support for "circa"/"c"/"BCE"/etc. in certain parts of the code).

bdarcus

I'm not that concerned about the UI aspects here (how users should enter the dates). I'm concerned with the integrity of the data, such that it can be reliably sorted, formatted, imported and exported.

So we need a reliable machine-readable way to handle these dates (internally). The old library hacks of "c. 524" are not really appropriate for the 21st century.