Upgrade StorageBetter Date Field
This is an old discussion that has not been active in a long time. Before commenting here, you should strongly consider starting a new discussion instead. If you think the content of this discussion is still relevant, you can link to it from your new discussion.
In rendering, a season is handled in much the same way as is done in the current Zotero implementation. It will appear on output only if no month and no day are specified. It replaces the month, and acquires the same formatting characteristics. It would be possible to allow seasons to be formatted independently, but it seems reasonable to wait and see whether that's necessary.
Seasons should probably not appear in CSL 1.0 localized dates of form "numeric". I don't think I've considered that wrinkle, it should probably be added to the test suite.
Anonymous. “Title text,” c.'s 1600.
Notice it's flipped. "c.1726-1732" yields "c.-1732 1726." For the former, mousing over the date field, I see "1600-00-00," which is itself an inaccurate representation of my intent, being far too precise. Obviously, I can't just fudge it.
I'm just not sure how to handle this, and would like to ask that it be considered as a legitimate and serious need. Thanks.
We hear you. In fact, the handling of fuzzy dates with ranges is currently ticketed as an issue for the citeproc-js CSL processor, put there by a library technologist with exactly the same concern.
What would be very helpful is a list of examples that ring the changes of how fuzzy date markers and ranges should play together in the output. Once all of the possibilities are in front of us, it will be easier to work back and figure out how to set things up at the start of the processing chain.
Another problem I can think of is the "Old Style" or Julian calendar, in which the new year starts in March. In the case of England prior to 1750, the year in dates between January and March was, and still is, often represented like this: "Feb. 16, 1615/16" (with 1616 being the "new" reckoning). Right now, I'm entering them like this: "Feb. 16, 1616 [1615/16]," but that is reduced to "February 16, 1616," which can confuse readers as to which calendar you're working with, and mess up a chronology.
As well as dashes in ranges, I see greater/less than signs ("before 1616" or "<1616"), and uncertain dates may contain brackets and/or question marks: "[1616?]"
I'd imagine that classicists and historians of the ancient world might have concerns about dates BCE, when the numbers get smaller going forward.
Re fuzzy dates and ranges, the reason for wanting a roster of possible forms before doing further work on it is that the citation processor input format, and therefore Zotero's internal machinery, will need to be altered to accomodate them. Making modifications that penetrate that deep is costly in time, so we'd want to get things pretty well covered with a single step (edit: as adamsmith says).
http://www.loc.gov/standards/datetime/features.html
http://wiki.whatwg.org/wiki/Time_element
As with names, dates are critical in many cases for basic functionality, like sorting.
Outputting dates "as is" is an outstanding ticket, so I don't think it's possible in Zotero 2.0.
As for age of organizations or traditions, that's irrelevant. What is relevant is that the LOC works with these kinds of data, and has identified these precise needs.
The pass-through of some dates doesn't seem like too much of a sacrifice, however, since I'm afraid we won't see anything approaching support for the LOC standard in the near future.
If Zotero were to support entry of the wide range of time expressions that the standards have described, how would input look? This is a serious question -- as I think about it, it seems to me that we would need to implement some sort of advanced date entry pop-up to handle such dates, so that users could explicitly choose calendars and whatnot. If that were done, then the field content (at the database level) could be in LOC date format, and we would just interact with it via a pop-up for complex dates or by entering the date string as it currently standards. The two modes could be alternated between a la one- and two-name input for authors.
Continuing my advanced data entry pipe dreams, a similar type of pop-up would be appropriate for multiple-language titles, and for multi-part names with ordering rules, titles, and dropping particles. Some UI innovations like this will be necessary if we ever want to get more complex item data into Zotero. Frank has put months of work into perfecting citation styling for carefully constructed bibliographic data, but we don't yet have a way of entering such carefully constructed data.
If you're using footnote styles without bibliographies (fbennett, and I suspect MG6), then you don't have to worry about sorting. It's not surprising you think literal dates are an OK solution.
If, OTOH, you work in the social sciences (like me, more-or-less), and you use author-date styles, then being able to reliably sort dates (including circa dates) is as critical a feature as there is. If a date doesn't sort correctly, then you can end up with wildly incorrect bibliographies, and mistakes with in-text citation references. Stuff breaks, and this is not a trivial thing.
For that reason, I consider literal dates a highly non-ideal solution, and I would like to isolate its use to a very narrow range of cases.
And I'm not actually suggesting we wait on the LoC to resolve the issues. Some of us have already contributed to that document (the list is open for contribution from anyone, BTW), and so we could always use some of the principles behind it before it's actually "done."
For example: if we support "circa" dates in Zotero (and we should), then it's critical that it works a) internationally (if different locales do things differently than "c. 1435", and b) for sorting. The LoCs draft proposal for this (adding a "~" at the end ) I believe comes from decades of practice with MARC, and has the characteristic it achieves the two requirements I note.
How this is done in the UI is a separate matter. It could be, for example, that people learn this syntax, that Zotero support already existing conventions like "c. 1435", or that the UI add some sort of checkbox by the date box. I have no strong opinion, so long as it's clear, and it works (broadly).
So to bring this down to something concrete, I see the following cases (which have been discussed elsewhere here, and which have been outlined in the EDTF documents):
- circa or uncertain dates ("c. 1456")
- date ranges ("1786-1787")
- compound dates ("March/April, 2000")
- different calendar systems
The first three, it seems to me, are the low-hanging fruit that we can and should support sooner than later.
FWIW, the RIS spec does not have literal dates. But it does have literal date parts. So the compound example in RIS would be "2000///March/April", which means the "March/April" bit it treated as a literal, but the "2000" is treated as a year. I actually think this is a pretty practical solution.
(1) Zotero translation
Read dates in a variety of formats and, if possible, convert them into a stable internal representation for automatic processing;
(2) Storage conversion and retrieval
Reduce the parts of the object produced by (1) to a string representation that can be stored in the Zotero DB and quickly restored to the internal form;
(3) Processor conversion
Transform the object produced by (1) to a form suitable for digestion by the CSL processor;
(4) Export conversion
Convert the object produced by (1) to a compact standard form that can be exchanged with other systems.
Standards dictate that the object generated at (1) be capable of expressing the elements and values of which the standard date exchange format used at step (4) is capable. User requirements dictate that all date forms (including non-standard ones) that enter the system at (1) be transferrable between systems in some way using the standard form used at (4).
My own concerns mostly start at step (3), which is why I probably seem to be talking at cross purposes at times. Just so it's clear for everyone, these three are all included in the CSL 1.0 date specification, and are supported (for rendering and for sorting) by the citeproc-js processor that will debut in Zotero 2.1. For step (1) above (parsing of input), the citeproc-js sources include date parsing code (disabled by default) that can produce the internal representation from the human-readable form of such dates. So signficant parts of this problem can be solved rather quickly and rather soon.
I am a german. I enter something like 12.9.2010 for September 12 2010.
Zotero parses and the displays "12.9.2010" J M T .
That is wild. because i entered T.M.J (D.M.Y in english, you probably got that.)
So now i think, my way of entering is wrong.
i enter 2010 9 12 according to the J M T directive i got form the UI.
then zotero shows: "2010 9 12" J T
Here, my wisdom left the building. Whiskey Tango Foxtrot id going on in z.?
Call this a layer 8 problem, if you like. The user here cannot for any sakes of it figure out properly, how and what zotero has made of their entered date. There should be less ambigouous ways to DISPLAY the result, once the field is parsed.
So please advise:
- how shall i enter the date?
- how shall i confirm that our little helper has got it right?
Thanks the lot, dear programmer!
I am aware of at least four desiderata here. One is to be liberal with regard to input format; Zotero is good at parsing dates so it does not force the user to supply it in a set format. The second is to be liberal with regard to input content: Zotero knows that "Autumn 1981" is used sometimes so it allows that, even though it parses only the year because Autumn doesn't resolve to a numeric month. The third is to show how the date has been parsed so that the user can check things are okay. The fourth is to show what is in the date field (which may be different from what's parsed due to #2).
The way these desiderata are implemented now is clearly confusing to users. Here are two options that meet the same desiderata but that make much more sense from a UI point of view:
A. Always store and display all dates in YYYY-(MM-(DD)) format insofar as they can be parsed and stored as such; display unparsed stuff as is. This yields "2008-03-27" and "Autum 1983". Display how Zotero has parsed it ("y m d" and "y", respectively) in a tooltip — it's not that important to users in the majority of cases.
A1. Leave it to the user how they want to display the date. Or obey the OS language settings. Both options are better than the current situation.
B. Keep things as they are now but adjust the "as parsed" display to match the order in the input field. This is a little less confusing that how things currently are, and therefore an improvement, but personally I think the prominence of the "y m d" display is just a case of nerdview. If the date field just displays as parsed, the problem is solved, especially if I can just say I want a certain display format across all entries.
My vote would thus be for option A. What's the use of displaying "March 27, 2009" if it has been parsed (and intended) as 2009-03-27? It's especially anoying when different repositories supply dates in different formats. I don't care that Reference Global gives "02/2009" while JSTOR gives "Feb., 1985". I think none of us cares really. If Zotero parses both as "y m", why not display them in YYYY-MM format (or some other specified format, see A1)?
Once again, this doesn't have implications for partly parsed dates, which are the only dates for which it makes sense to be displayed as literals.
Or am I missing something?